You are on page 1of 32

PINGIDENTITY.

COM
OPENID CONNECT
Ping Identity Education
OAUTH REVIEW
§ Joe wants to
buy a song
from Tunes
Partner.

§ Joe wants to
pay with his
bank, IDTel.

Copyright © 2015 Ping Identity Corp. All rights reserved.


OAUTH REVIEW
§ Joe gets
redirected to
IDTel to
!
authenticate.

• Joe is then asked to


authorize the request.

Copyright © 2015 Ping Identity Corp. All rights reserved.


!
OAUTH REVIEW

§ Joe is sent back to the redirect URI, the Tunes Partner


website
– Tunes Partner receives an access token
§ Tunes Partner knows it now has access to a resource, but
has no user information
– There is a hole in the authentication loop
Copyright © 2015 Ping Identity Corp. All rights reserved.
AND WHAT IF TUNES PARTNER WANTS
USER INFORMATION?

- and -
“Thanks for your purchase, unknown I have no metrics on which types of people
buy this type of music
person!

Versus…
AND WHAT IF TUNES PARTNER WANTS
USER INFORMATION?

- and -
“Thanks for your purchase, unknown person! I have no metrics on which types of people buy
this type of music

Versus…

“Thanks for your purchase, Joe! - and - We should cater our marketing to 25+
males in the southern United States

Copyright © 2015 Ping Identity Corp. All rights reserved.


EXTENSION TO OAUTH – ID_TOKENS

§ The first problem – what user is this access


token for? – is solved with id_tokens.
Service Provider OAuth Authorization Server
User

AuthZ
Endpoint

Token
3rd
Party Endpoint Validation
Client Endpoint

Copyright © 2015 Ping Identity Corp. All rights reserved.


SO – WHAT’S AN ID_TOKEN?
Service Provider OAuth Authorization Server

AuthZ
"iss": "https://as.idtel.com",
User
Endpoint (‘issuer’. Did this come from the right
Token
authorization server (AS)?)
Endpoint
Validation
Endpoint
“user_id": "24400320",
3 rd Party
Client
(Which user did the AS authenticate?
Also called “sub” for “subject”. Will
decode to “joe”, for instance.)
HTTP/1.1 200 OK Content-Type: application/json Cache-
Control: no-store Pragma: no-cache
{ "aud": "s6BhdRkqt3",
"access_token":"SlAV32hkKG", Base64url
"token_type":"bearer", "expires_in":3600, (‘audience’. This should decode to
decode
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"id_token":"eyJ0 ... NiJ9.eyJ1c ...
“tunes_partner” – my client_id, so this
I6IjIifX0.DeWt4Qu .”
}
token was meant for me)

• A security token "exp": 1311281970,


(‘expiry time of token.’ Is this token
• JSON Web Token (JWT) still valid?)

"iat": 1311280970
(‘issued at time’)
ID_TOKENS GIVE THE CLIENT THE USER_ID

“Thanks for your purchase, Joe!


“Thanks for your purchase, unknown
user!”
But we still don’t know anything else about the user…

I still have no metrics on which types of people


buy this type of music??

Copyright © 2015 Ping Identity Corp. All rights reserved.


EXTENSION TO OAUTH – USERINFO
ENDPOINT
Server/Provider OAuth Server/Provider OAuth
Authorization Server Authorization Server
{
AuthZ
Endpoint
AuthZ
Endpoint
”user_id":
"248289761001",
Token
Endpoint
Token
Endpoint
"name":
Validation
Validation
Endpoint
UserInfo
Endpoint
”Joe Saml”,
Endpoint
"preferred_username":
"j.saml",
Access Token
"email":
”jsaml@example.com",
“age”:
Claims
“27”
(user info)
3 rd Party “location”:
Client
“Florida”
}

Copyright © 2015 Ping Identity Corp. All rights reserved.


SO NOW WE KNOW OPENID
CONNECT!
§ Sits on top of the OAuth 2.0 authorization
framework
– More scopes!
§ id_tokens
– “Unknown user bought a song,” vs “Joe bought a song.”

§ Userinfo endpoints with claims


– “I don’t know anything about this user,” versus “This user
is 27 from Florida.”
OPENID CONNECT SCOPES
• In OAuth, we request access to protected resources by requesting
access to scopes
• (charge $10, post to Facebook wall, etc…)

§ OpenID Connect scope


• Gets the client an id_token

• To request claims, we need to include those as


scopes, too.
• Email address, profile, location…
• Anything from the userinfo endpoint
REQUESTING AN ID_TOKEN – OPENID SCOPE
NORMAL AUTHENTICATION,
AUTHORIZATION
NORMAL; RECEIVE AUTHORIZATION
CODE
GET BACK ID_TOKEN AND
ACCESS_TOKEN
CLIENT VALIDATES ID_TOKEN
NORMAL; VERIFY ACCESS TOKEN
WITH RESOURCE SERVER
SO NOW WITH THE ID_TOKEN, WE HAVE
THE USER ID

The user’s ID is dflutie But what’s their birthday?

§ The OpenID scope gets us the id_token, but what


about more claims?

§ Access token currently only for username

§ If we want the user’s birthday, we need to include a


scope for that
Copyright © 2015 Ping Identity Corp. All rights reserved.
GETTING THE USER INFORMATION
§ But: no special “birthday” scope.
– “birthday” is an attribute contained in another scope – the profile
scope

§ The OpenID Connect documentation lists scopes and their


components

§ “Profile” includes:
– the End-User's default profile Claims, which are: name,
family_name, given_name, middle_name, nickname,
preferred_username, profile, picture, website, gender, birthdate,
zoneinfo, locale, and updated_at.
Copyright © 2015 Ping Identity Corp. All rights reserved.
REQUESTING AN ID_TOKEN – OPENID
SCOPE
AUTHORIZE THE OPENID AND
PROFILE SCOPES
CLIENT REQUEST USER INFO, FOR
PROFILE SCOPE

{“sub”:”dflutie”,“birthdate”:“01/24/62”}
WEB APPLICATION WITH OPENID CONNECT: FLOW
• Issuing id tokens and claims to a web application

1
1) Web app launches browser,
AuthZ
Endpoint in which user authenticates
to the Authorization Server
Token
Endpoint (and grants authorization)
Validation UserInfo
Endpoint Endpoint

Copyright © 2015 Ping Identity Corp. All rights reserved.


WEB APPLICATION WITH OPENID CONNECT: FLOW
• Issuing id tokens and claims to a web application

1
1) Web app launches browser,
AuthZ
2 Endpoint in which user authenticates
to the Authorization Server
Token
Endpoint (and grants authorization)
Validation UserInfo
2) Authorization server
Endpoint Endpoint returns Auth Code to web
app through browser

Copyright © 2015 Ping Identity Corp. All rights reserved.


WEB APPLICATION WITH OPENID CONNECT: FLOW
• Issuing id tokens and claims to a web application

1
1) Web app launches browser,
AuthZ
2 Endpoint in which user authenticates
to the Authorization Server
Token
Endpoint (and grants authorization)
Validation UserInfo
2) Authorization server
3 Endpoint Endpoint returns Auth Code to web
app through browser
3) Web app exchanges code
for access token and id
token

Copyright © 2015 Ping Identity Corp. All rights reserved.


WEB APPLICATION WITH OPENID CONNECT: FLOW
• Issuing id tokens and claims to a web application
1) Web app launches browser, in
1
which user authenticates to
AuthZ
Endpoint
the Authorization Server (and
2
grants authorization)
Token
Endpoint 2) Authorization server returns
Auth Code to web app
3
Validation
Endpoint
UserInfo
Endpoint
through browser
3) Web app exchanges code for
access token and id token
4 4) Instead of sending the access
token to the Resource Server,
the web app sends the access
token to the Userinfo
Endpoint

Copyright © 2015 Ping Identity Corp. All rights reserved.


WEB APPLICATION WITH OPENID CONNECT: FLOW
• Issuing id tokens and claims to a web application
1) Web app launches browser, in
1 which user authenticates to the
AuthZ
Authorization Server (and grants
2 Endpoint authorization)
Token 2) Authorization server returns
Endpoint Auth Code to web app through
browser
Validation UserInfo
3 Endpoint Endpoint 3) Web app exchanges code for
access token and id token
4) Instead of sending the access
4 token to the Resource Server,
the web app sends the access
5
token to the Userinfo Endpoint
5) Authorization Server returns
requested user information
(claims) from the userinfo
endpoint

Copyright © 2015 Ping Identity Corp. All rights reserved.


SO NOW WE KNOW OPENID CONNECT!
§ id_tokens
– “Tunes Partner unknown user bought a song,” versus “Tunes Partner user Joe bought a
song.”
§ Userinfo endpoints with claims
– “I don’t know anything about this user,” versus “This user is 27 from Florida.”
§ Scopes:
– OpenID Connect scope will get the client an id_token
– More information with OpenID connect about the user
› Email address, profile, location…
› Anything in that claim from the userinfo
endpoint

Copyright © 2015 Ping Identity Corp. All rights reserved.


BIG OPENID CONNECT USE CASE: SSO
Single Sign on to third party client: 1. User clicks “Log in with
____ account”
Authorization code or implicit flow - Google, Facebook,
etc….

1
AuthZ
2. OpenID Connect
Endpoint request:
Token
- Scope: openID
2
Endpoint Connect
- “I need the userID”
3
3. Client receives access
token and id token:
- Doesn’t use/need
access token
3rd Party
Client
PINGIDENTITY.COM

You might also like