CIS14: Developing with OAuth and OIDC Connect
1 like1,375 views
The document discusses OAuth 2.0 and OpenID Connect, explaining that OAuth is primarily for authorization while OpenID Connect adds an authentication layer on top of it. It details various grant types for OAuth and OpenID Connect, including authorization code, implicit flow, and resource owner credentials, along with example code snippets for implementing these flows. Key points include the validation of ID tokens, claims, and user information retrieval for enhanced security and user management.
![OpenID
Connect
• OpenID
Connect
1.0
is
a
simple
iden;ty
layer
on
top
of
the
OAuth
2.0
[RFC6749]
protocol.
It
enables
Clients
to
verify
the
iden;ty
of
the
End-‐
User
based
on
the
authen;ca;on
performed
by
an
Authoriza;on
Server,
as
well
as
to
obtain
basic
profile
informa;on
about
the
End-‐User
in
an
interoperable
and
REST-‐like
manner.](https://image.slidesharecdn.com/zck7q6cjt3iij9erzwdn-signature-e77353a5531666e85fadeb0e4ebdcbd4e7522e2f525b50388570d11bd88051f3-poli-140804132448-phpapp02/85/CIS14-Developing-with-OAuth-and-OIDC-Connect-5-320.jpg)
![The
ID
token
If
the
ID
Token
is
encrypted,
decrypt
it
using
the
keys
and
algorithms
that
the
Client
specified
during
Registra;on
that
the
OP
was
to
use
to
encrypt
the
ID
Token.
If
encryp;on
was
nego;ated
with
the
OP
at
Registra;on
;me
and
the
ID
Token
is
not
encrypted,
the
RP
SHOULD
reject
it.
The
Issuer
Iden;fier
for
the
OpenID
Provider
(which
is
typically
obtained
during
Discovery)
MUST
exactly
match
the
value
of
the
iss
(issuer)
Claim.
The
Client
MUST
validate
that
the
aud
(audience)
Claim
contains
its
client_id
value
registered
at
the
Issuer
iden;fied
by
the
iss
(issuer)
Claim
as
an
audience.
The
aud
(audience)
Claim
MAY
contain
an
array
with
more
than
one
element.
The
ID
Token
MUST
be
rejected
if
the
ID
Token
does
not
list
the
Client
as
a
valid
audience,
or
if
it
contains
addi;onal
audiences
not
trusted
by
the
Client.
If
the
ID
Token
contains
mul;ple
audiences,
the
Client
SHOULD
verify
that
an
azp
Claim
is
present.
If
an
azp
(authorized
party)
Claim
is
present,
the
Client
SHOULD
verify
that
its
client_id
is
the
Claim
Value.
If
the
ID
Token
is
received
via
direct
communica;on
between
the
Client
and
the
Token
Endpoint
(which
it
is
in
this
flow),
the
TLS
server
valida;on
MAY
be
used
to
validate
the
issuer
in
place
of
checking
the
token
signature.
The
Client
MUST
validate
the
signature
of
all
other
ID
Tokens
according
to
JWS
[JWS]
using
the
algorithm
specified
in
the
JWT
alg
header
parameter.
The
Client
MUST
use
the
keys
provided
by
the
Issuer.
The
alg
value
SHOULD
be
the
default
of
RS256
or
the
algorithm
sent
by
the
Client
in
the
id_token_signed_response_alg
parameter
during
Registra;on.
If
the
JWT
alg
header
parameter
uses
a
MAC
based
algorithm
such
as
HS256,
HS384,
or
HS512,
the
octets
of
the
UTF-‐8
representa;on
of
the
client_secret
corresponding
to
the
client_id
contained
in
the
aud
(audience)
Claim
are
used
as
the
key
to
validate
the
signature.
For
MAC
based
algorithms,
the
behavior
is
unspecified
if
the
aud
is
mul;-‐
valued
or
if
an
azp
value
is
present
that
is
different
than
the
aud
value.
The
current
;me
MUST
be
before
the
;me
represented
by
the
exp
Claim.
The
iat
Claim
can
be
used
to
reject
tokens
that
were
issued
too
far
away
from
the
current
;me,
limi;ng
the
amount
of
;me
that
nonces
need
to
be
stored
to
prevent
abacks.
The
acceptable
range
is
Client
specific.
If
a
nonce
value
was
sent
in
the
Authen;ca;on
Request,
a
nonce
Claim
MUST
be
present
and
its
value
checked
to
verify
that
it
is
the
same
value
as
the
one
that
was
sent
in
the
Authen;ca;on
Request.
The
Client
SHOULD
check
the
nonce
value
for
replay
abacks.
The
precise
method
for
detec;ng
replay
abacks
is
Client
specific.
If
the
acr
Claim
was
requested,
the
Client
SHOULD
check
that
the
asserted
Claim
Value
is
appropriate.
The
meaning
and
processing
of
acr
Claim
Values
is
out
of
scope
for
this
specifica;on.
If
the
auth_;me
Claim
was
requested,
either
through
a
specific
request
for
this
Claim
or
by
using
the
max_age
parameter,
the
Client
SHOULD
check
the
auth_;me
Claim
value
and
request
re-‐authen;ca;on
if
it
determines
too
much
;me
has
elapsed
since
the
last
End-‐User
authen;ca;on.](https://image.slidesharecdn.com/zck7q6cjt3iij9erzwdn-signature-e77353a5531666e85fadeb0e4ebdcbd4e7522e2f525b50388570d11bd88051f3-poli-140804132448-phpapp02/85/CIS14-Developing-with-OAuth-and-OIDC-Connect-18-320.jpg)
![More…
Member
Type
Descrip;on
sub
string
Subject
-‐
Iden;fier
for
the
End-‐User
at
the
Issuer.
name
string
End-‐User's
full
name
in
displayable
form
including
all
name
parts,
possibly
including
;tles
and
suffixes,
ordered
according
to
the
End-‐User's
locale
and
preferences.
given_name
string
Given
name(s)
or
first
name(s)
of
the
End-‐User.
Note
that
in
some
cultures,
people
can
have
mul;ple
given
names;
all
can
be
present,
with
the
names
being
separated
by
space
characters.
family_name
string
Surname(s)
or
last
name(s)
of
the
End-‐User.
Note
that
in
some
cultures,
people
can
have
mul;ple
family
names
or
no
family
name;
all
can
be
present,
with
the
names
being
separated
by
space
characters.
middle_name
string
Middle
name(s)
of
the
End-‐User.
Note
that
in
some
cultures,
people
can
have
mul;ple
middle
names;
all
can
be
present,
with
the
names
being
separated
by
space
characters.
Also
note
that
in
some
cultures,
middle
names
are
not
used.
nickname
string
Casual
name
of
the
End-‐User
that
may
or
may
not
be
the
same
as
the
given_name.
For
instance,
a
nickname
value
of
Mike
might
be
returned
alongside
a
given_name
value
of
Michael.
preferred_username
string
Shorthand
name
by
which
the
End-‐User
wishes
to
be
referred
to
at
the
RP,
such
as
janedoe
or
j.doe.
This
value
MAY
be
any
valid
JSON
string
including
special
characters
such
as
@,
/,
or
whitespace.
The
RP
MUST
NOT
rely
upon
this
value
being
unique,
as
discussed
in
Sec;on
5.7.
profile
string
URL
of
the
End-‐User's
profile
page.
The
contents
of
this
Web
page
SHOULD
be
about
the
End-‐User.
picture
string
URL
of
the
End-‐User's
profile
picture.
This
URL
MUST
refer
to
an
image
file
(for
example,
a
PNG,
JPEG,
or
GIF
image
file),
rather
than
to
a
Web
page
containing
an
image.
Note
that
this
URL
SHOULD
specifically
reference
a
profile
photo
of
the
End-‐User
suitable
for
displaying
when
describing
the
End-‐User,
rather
than
an
arbitrary
photo
taken
by
the
End-‐User.
website
string
URL
of
the
End-‐User's
Web
page
or
blog.
This
Web
page
SHOULD
contain
informa;on
published
by
the
End-‐User
or
an
organiza;on
that
the
End-‐User
is
affiliated
with.
email
string
End-‐User's
preferred
e-‐mail
address.
Its
value
MUST
conform
to
the
RFC
5322
[RFC5322]
addr-‐spec
syntax.
The
RP
MUST
NOT
rely
upon
this
value
being
unique,
as
discussed
in
Sec;on
5.7.
email_verified
boolean
True
if
the
End-‐User's
e-‐mail
address
has
been
verified;
otherwise
false.
When
this
Claim
Value
is
true,
this
means
that
the
OP
took
affirma;ve
steps
to
ensure
that
this
e-‐mail
address
was
controlled
by
the
End-‐User
at
the
;me
the
verifica;on
was
performed.
The
means
by
which
an
e-‐mail
address
is
verified
is
context-‐specific,
and
dependent
upon
the
trust
framework
or
contractual
agreements
within
which
the
par;es
are
opera;ng.
gender
string
End-‐User's
gender.
Values
defined
by
this
specifica;on
are
female
and
male.
Other
values
MAY
be
used
when
neither
of
the
defined
values
are
applicable.
birthdate
string
End-‐User's
birthday,
represented
as
an
ISO
8601:2004
[ISO8601‑2004]
YYYY-‐MM-‐DD
format.
The
year
MAY
be
0000,
indica;ng
that
it
is
omibed.
To
represent
only
the
year,
YYYY
format
is
allowed.
Note
that
depending
on
the
underlying
pla€orm's
date
related
func;on,
providing
just
year
can
result
in
varying
month
and
day,
so
the
implementers
need
to
take
this
factor
into
account
to
correctly
process
the
dates.
zoneinfo
string
String
from
zoneinfo
[zoneinfo]
;me
zone
database
represen;ng
the
End-‐User's
;me
zone.
For
example,
Europe/Paris
or
America/Los_Angeles.
locale
string
End-‐User's
locale,
represented
as
a
BCP47
[RFC5646]
language
tag.
This
is
typically
an
ISO
639-‐1
Alpha-‐2
[ISO639‑1]
language
code
in
lowercase
and
an
ISO
3166-‐1
Alpha-‐2
[ISO3166‑1]
country
code
in
uppercase,
separated
by
a
dash.
For
example,
en-‐US
or
fr-‐CA.
As
a
compa;bility
note,
some
implementa;ons
have
used
an
underscore
as
the
separator
rather
than
a
dash,
for
example,
en_US;
Relying
Par;es
MAY
choose
to
accept
this
locale
syntax
as
well.
phone_number
string
End-‐User's
preferred
telephone
number.
E.164
[E.164]
is
RECOMMENDED
as
the
format
of
this
Claim,
for
example,
+1
(425)
555-‐1212
or
+56
(2)
687
2400.
If
the
phone
number
contains
an
extension,
it
is
RECOMMENDED
that
the
extension
be
represented
using
the
RFC
3966
[RFC3966]
extension
syntax,
for
example,
+1
(604)
555-‐1234;ext=5678.
phone_number_verified
boolean
True
if
the
End-‐User's
phone
number
has
been
verified;
otherwise
false.
When
this
Claim
Value
is
true,
this
means
that
the
OP
took
affirma;ve
steps
to
ensure
that
this
phone
number
was
controlled
by
the
End-‐User
at
the
;me
the
verifica;on
was
performed.
The
means
by
which
a
phone
number
is
verified
is
context-‐specific,
and
dependent
upon
the
trust
framework
or
contractual
agreements
within
which
the
par;es
are
opera;ng.
When
true,
the
phone_number
Claim
MUST
be
in
E.164
format
and
any
extensions
MUST
be
represented
in
RFC
3966
format.
address
JSON
object
End-‐User's
preferred
postal
address.
The
value
of
the
address
member
is
a
JSON
[RFC4627]
structure
containing
some
or
all
of
the
members
defined
in
Sec;on
5.1.1.
updated_at
number
Time
the
End-‐User's
informa;on
was
last
updated.
Its
value
is
a
JSON
number
represen;ng
the
number
of
seconds
from
1970-‐01-‐01T0:0:0Z
as
measured
in
UTC
un;l
the
date/
;me.](https://image.slidesharecdn.com/zck7q6cjt3iij9erzwdn-signature-e77353a5531666e85fadeb0e4ebdcbd4e7522e2f525b50388570d11bd88051f3-poli-140804132448-phpapp02/85/CIS14-Developing-with-OAuth-and-OIDC-Connect-24-320.jpg)
CIS14: Developing with OAuth and OIDC Connect
- 1. Developing with OAuth and OpenID Connect David Chase Senior So9ware Architect Ping Iden;ty
- 3. OAuth or OpenID Connect, which one?
- 4. OAuth2.0 • An authoriza;on grant is a creden;al represen;ng the resource owner's authoriza;on to access its protected resources.
- 5. OpenID Connect • OpenID Connect 1.0 is a simple iden;ty layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the iden;ty of the End-‐ User based on the authen;ca;on performed by an Authoriza;on Server, as well as to obtain basic profile informa;on about the End-‐User in an interoperable and REST-‐like manner.
- 6. OAuth or OpenID Connect, which one? • OAuth is for authoriza;on • OpenID Connects adds authen;ca;on to authoriza;on
- 7. Choosing a Grant Type for OAuth • Authoriza;on Code • Implicit • Resource Owner Creden;als • Refresh Token • Client Creden;als • Extension (i.e. SAML 2.0 Bearer)
- 8. Authoriza;on Code var reques;fy = require('reques;fy'); reques;fy.post('hbp://example.com', { redirect_uri: 'hbps%3A%2F%2Fexample.org%2callback', response_type:'code', client_id:'myId’, scope:’read’, state:’343msdjasd9k2’ }) .then(func;on(response) { // Get the response body (JSON parsed or jQuery object for XMLs) response.getBody(); });
- 9. Implicit var reques;fy = require('reques;fy'); reques;fy.post('hbp://example.com', { redirect_uri: 'hbps%3A%2F%2Fexample.org%2callback', response_type:’token', client_id:'myId’, scope:’read’, state:’343msdjasd9k2’ }) .then(func;on(response) { // Get the response body (JSON parsed or jQuery object for XMLs) response.getBody(); });
- 10. Resource Owner Creden;als var reques;fy = require('reques;fy'); reques;fy.post('hbp://example.com', { redirect_uri: 'hbps%3A%2F%2Fexample.org%2callback', grant_type:’password', username:’joe’, password:’2Federate’, client_id:'myId’, scope:’read’, }) .then(func;on(response) { // Get the response body (JSON parsed or jQuery object for XMLs) response.getBody(); });
- 11. Refresh Token var reques;fy = require('reques;fy'); reques;fy.post('hbp://example.com', { grant_type:’refresh_token’, client_id:’myid’, client_secret:‘1955279925675241571’, refresh_token: ‘3MVG9lKcPoNINVBIPJjdw1J9LLM82HnFVVX19KY1uA5mu0 QqEWhqKpoW3svG3XHrXDiCQjK1mdgAvhCscA9GE’ }) .then(func;on(response) { // Get the response body (JSON parsed or jQuery object for XMLs) response.getBody(); });
- 12. Client Creden;als var reques;fy = require('reques;fy'); reques;fy.post('hbp://example.com', { redirect_uri: 'hbps%3A%2F%2Fexample.org%2callback', grant_type:’client_creden;als’, client_secret:’2Federate’, client_id:'myId’, scope:’read’, }) .then(func;on(response) { // Get the response body (JSON parsed or jQuery object for XMLs) response.getBody(); });
- 13. Extension …
- 14. Choosing a Grant Type for OpenID Connect • Authoriza;on Code Flow • Implicit Flow • Hybrid Flow
- 15. Authoriza;on Code Flow 1. Client prepares an Authen;ca;on Request containing the desired request parameters. 2. Client sends the request to the Authoriza;on Server. 3. Authoriza;on Server Authen;cates the End-‐User. 4. Authoriza;on Server obtains End-‐User Consent/Authoriza;on. 5. Authoriza;on Server sends the End-‐User back to the Client with an Authoriza;on Code. 6. Client requests a response using the Authoriza;on Code at the Token Endpoint. 7. Client receives a response that contains an ID Token and Access Token in the response body. 8. Client validates the ID token and retrieves the End-‐User's Subject Iden;fier.
- 16. Authoriza;on Code Flow var reques;fy = require('reques;fy'); reques;fy.post('hbp://example.com', { redirect_uri: 'hbps%3A%2F%2Fexample.org%2callback', response_type:'code', client_id:'myId’, scope:’read’, state:’343msdjasd9k2’ }) .then(func;on(response) { // Get the response body (JSON parsed or jQuery object for XMLs) response.getBody(); });
- 17. Authoriza;on Code Token Response { "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-‐cwh3LO-‐p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-‐gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-‐rvKMzqg" }
- 18. The ID token If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registra;on that the OP was to use to encrypt the ID Token. If encryp;on was nego;ated with the OP at Registra;on ;me and the ID Token is not encrypted, the RP SHOULD reject it. The Issuer Iden;fier for the OpenID Provider (which is typically obtained during Discovery) MUST exactly match the value of the iss (issuer) Claim. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer iden;fied by the iss (issuer) Claim as an audience. The aud (audience) Claim MAY contain an array with more than one element. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains addi;onal audiences not trusted by the Client. If the ID Token contains mul;ple audiences, the Client SHOULD verify that an azp Claim is present. If an azp (authorized party) Claim is present, the Client SHOULD verify that its client_id is the Claim Value. If the ID Token is received via direct communica;on between the Client and the Token Endpoint (which it is in this flow), the TLS server valida;on MAY be used to validate the issuer in place of checking the token signature. The Client MUST validate the signature of all other ID Tokens according to JWS [JWS] using the algorithm specified in the JWT alg header parameter. The Client MUST use the keys provided by the Issuer. The alg value SHOULD be the default of RS256 or the algorithm sent by the Client in the id_token_signed_response_alg parameter during Registra;on. If the JWT alg header parameter uses a MAC based algorithm such as HS256, HS384, or HS512, the octets of the UTF-‐8 representa;on of the client_secret corresponding to the client_id contained in the aud (audience) Claim are used as the key to validate the signature. For MAC based algorithms, the behavior is unspecified if the aud is mul;-‐ valued or if an azp value is present that is different than the aud value. The current ;me MUST be before the ;me represented by the exp Claim. The iat Claim can be used to reject tokens that were issued too far away from the current ;me, limi;ng the amount of ;me that nonces need to be stored to prevent abacks. The acceptable range is Client specific. If a nonce value was sent in the Authen;ca;on Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authen;ca;on Request. The Client SHOULD check the nonce value for replay abacks. The precise method for detec;ng replay abacks is Client specific. If the acr Claim was requested, the Client SHOULD check that the asserted Claim Value is appropriate. The meaning and processing of acr Claim Values is out of scope for this specifica;on. If the auth_;me Claim was requested, either through a specific request for this Claim or by using the max_age parameter, the Client SHOULD check the auth_;me Claim value and request re-‐authen;ca;on if it determines too much ;me has elapsed since the last End-‐User authen;ca;on.
- 19. Before you start coding… hbp://openid.net/developers/libraries/ Libraries list for: C, C#, Java, PHP, Python, Ruby, Javascript And Products…
- 20. ID token { "iss": "hbps://server.example.com", "sub": "24400320", "aud": "s6BhdRkqt3", "nonce": "n-‐0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970, "auth_;me": 1311280969, "acr": "urn:mace:incommon:iap:silver" }
- 21. Implicit Flow Client prepares an Authen;ca;on Request containing the desired request parameters. Client sends the request to the Authoriza;on Server. Authoriza;on Server Authen;cates the End-‐User. Authoriza;on Server obtains End-‐User Consent/Authoriza;on. Authoriza;on Server sends the End-‐User back to the Client with an ID Token and, if requested, an Access Token. Client validates the ID token and retrieves the End-‐User's Subject Iden;fier.
- 22. Calling the User Info Endpoint GET /userinfo HTTP/1.1 Host: server.example.com Authoriza;on: Bearer SlAV32hkK
- 23. Claims { "sub": "248289761001", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "preferred_username": "j.doe", "email": "[email protected]", "picture": "hbp://example.com/janedoe/me.jpg" }
- 24. More… Member Type Descrip;on sub string Subject -‐ Iden;fier for the End-‐User at the Issuer. name string End-‐User's full name in displayable form including all name parts, possibly including ;tles and suffixes, ordered according to the End-‐User's locale and preferences. given_name string Given name(s) or first name(s) of the End-‐User. Note that in some cultures, people can have mul;ple given names; all can be present, with the names being separated by space characters. family_name string Surname(s) or last name(s) of the End-‐User. Note that in some cultures, people can have mul;ple family names or no family name; all can be present, with the names being separated by space characters. middle_name string Middle name(s) of the End-‐User. Note that in some cultures, people can have mul;ple middle names; all can be present, with the names being separated by space characters. Also note that in some cultures, middle names are not used. nickname string Casual name of the End-‐User that may or may not be the same as the given_name. For instance, a nickname value of Mike might be returned alongside a given_name value of Michael. preferred_username string Shorthand name by which the End-‐User wishes to be referred to at the RP, such as janedoe or j.doe. This value MAY be any valid JSON string including special characters such as @, /, or whitespace. The RP MUST NOT rely upon this value being unique, as discussed in Sec;on 5.7. profile string URL of the End-‐User's profile page. The contents of this Web page SHOULD be about the End-‐User. picture string URL of the End-‐User's profile picture. This URL MUST refer to an image file (for example, a PNG, JPEG, or GIF image file), rather than to a Web page containing an image. Note that this URL SHOULD specifically reference a profile photo of the End-‐User suitable for displaying when describing the End-‐User, rather than an arbitrary photo taken by the End-‐User. website string URL of the End-‐User's Web page or blog. This Web page SHOULD contain informa;on published by the End-‐User or an organiza;on that the End-‐User is affiliated with. email string End-‐User's preferred e-‐mail address. Its value MUST conform to the RFC 5322 [RFC5322] addr-‐spec syntax. The RP MUST NOT rely upon this value being unique, as discussed in Sec;on 5.7. email_verified boolean True if the End-‐User's e-‐mail address has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirma;ve steps to ensure that this e-‐mail address was controlled by the End-‐User at the ;me the verifica;on was performed. The means by which an e-‐mail address is verified is context-‐specific, and dependent upon the trust framework or contractual agreements within which the par;es are opera;ng. gender string End-‐User's gender. Values defined by this specifica;on are female and male. Other values MAY be used when neither of the defined values are applicable. birthdate string End-‐User's birthday, represented as an ISO 8601:2004 [ISO8601‑2004] YYYY-‐MM-‐DD format. The year MAY be 0000, indica;ng that it is omibed. To represent only the year, YYYY format is allowed. Note that depending on the underlying pla€orm's date related func;on, providing just year can result in varying month and day, so the implementers need to take this factor into account to correctly process the dates. zoneinfo string String from zoneinfo [zoneinfo] ;me zone database represen;ng the End-‐User's ;me zone. For example, Europe/Paris or America/Los_Angeles. locale string End-‐User's locale, represented as a BCP47 [RFC5646] language tag. This is typically an ISO 639-‐1 Alpha-‐2 [ISO639‑1] language code in lowercase and an ISO 3166-‐1 Alpha-‐2 [ISO3166‑1] country code in uppercase, separated by a dash. For example, en-‐US or fr-‐CA. As a compa;bility note, some implementa;ons have used an underscore as the separator rather than a dash, for example, en_US; Relying Par;es MAY choose to accept this locale syntax as well. phone_number string End-‐User's preferred telephone number. E.164 [E.164] is RECOMMENDED as the format of this Claim, for example, +1 (425) 555-‐1212 or +56 (2) 687 2400. If the phone number contains an extension, it is RECOMMENDED that the extension be represented using the RFC 3966 [RFC3966] extension syntax, for example, +1 (604) 555-‐1234;ext=5678. phone_number_verified boolean True if the End-‐User's phone number has been verified; otherwise false. When this Claim Value is true, this means that the OP took affirma;ve steps to ensure that this phone number was controlled by the End-‐User at the ;me the verifica;on was performed. The means by which a phone number is verified is context-‐specific, and dependent upon the trust framework or contractual agreements within which the par;es are opera;ng. When true, the phone_number Claim MUST be in E.164 format and any extensions MUST be represented in RFC 3966 format. address JSON object End-‐User's preferred postal address. The value of the address member is a JSON [RFC4627] structure containing some or all of the members defined in Sec;on 5.1.1. updated_at number Time the End-‐User's informa;on was last updated. Its value is a JSON number represen;ng the number of seconds from 1970-‐01-‐01T0:0:0Z as measured in UTC un;l the date/ ;me.
- 25. Handling Refresh Tokens and Managing Sessions • Web Server/Applica;on – Refresh Token • Mobile/Javascript Browser Client – No Refresh Token
- 26. Concerns • Losing Tokens (Open Redirects) • Losing client creden;als • OAuth isn’t SSO!
- 27. Ques;ons / References Confidential — do not distribute Copyright © 2013 Ping Identity Corp.All rights reserved. 27 OpenID Connect http://openid.net/connect OAuth 2.0 http://oauth.net/2 JSON Web Token (JWT) http://tools.ietf.org/html/draft-ietf-oauth-json-web-token