OAuth/OpenID Connect and JWT connection frontend and backend Author: Peter Varga, DPC Consulting Event: HOUG Szakmai nap 2015, 2015.10.07

1. Full Stack Security
OAuth/OpenID Connect and JWT
connecting frontend and backend
DPC, Oct 2015
Peter.Varga
@thevrg
http://dpc.hu
DPC Consulting Ltd

2. Agenda
● OAuth 2.0
● OpenID Connect
● JSON Web Token (JWT)
● Demo
● Q&A

3. OAuth 2.0

4. OAuth 2.0
● Open standard for authorization (RFC 6749)
● Provides a method for a third-party to access
resources on behalf of a resource owner
● OAuth 2.0 token are also used to imply
authentication
● OAuth 2.0 process consists of:
1. Obtaining an authorization grant
2. Obtaining an access token
3. Using the access token to make requests

5. Problems Addressed by OAuth 2.0
● In traditional model, a third-party given access to a
resource owner resources means:
– Third-party must store the resource owner credentials
– Third-party access is not limited in scope
– Third-party access is not limited in time
– The resource owner cannot revoke access to one third-
party only; the only way to revoke access being a change
in credentials
● OAuth2 presents an alternative solution addressing
each of these issues

6. OAuth 2.0 Roles
● Client
● Resource Owner
● Authorization Server
● Resource Server

7. OAuth 2.0 Terminology
● Authorization Grant:
– credentials representing the resource owner’s
authorization
– used by the client to obtain an access token
● Access Token:
– credentials used to access protected resources
– represents specific scopes and durations of access
● Refresh Token:
– credentials used to obtain a new access token when
current access token becomes invalid
● Scope:
– determines the specific resources that can be accessed
and the duration of the grant

8. OAuth 2.0 Clients
● Confidential: can protect their credentials
– web applications
● Public: risk to expose their credentials
– mobile phone apps
– desktop clients
– web-browsers
● Before OAuth2 process can take place, the client
must register to the authorization server

9. Obtaining Access Token
● There are different ways to obtain an access token:
– Authorization Code
– Implicit
– Resource Owner Password Credentials
– Client Credentials
– Extension Mechanism; e.g. SAML2 Token Insertion
● All communication must be performed through a
secure channel

10. Authorization Code Flow

11. Authorization Code Flow (1-3)
1-2: Authorization Request
https://oauthprovider.example.com/oauth/authorize?
response_type=code&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=rea
d
● response_type= code
● client_id=CLIENT_ID
● redirect_uri=CALLBACK_URL
● scope=read
3: User authorizes request
● User authenticates if not authenticated yet

12. Authorization Code Flow (4-7)
4-5: Browser is redirected to Client’s CALLBACK_URL
https://sample.oauthclient.com/callback?code= AUTHORIZATION_CODE
● code=AUTHORIZATION_CODE
6: Client requests Access Token
POST https://oauthprovider.example.com/oauth/token
Content-Type: application/x-www-form-urlencoded
client_id=CLIENT_ID&client_secret= CLIENT_SECRET&grant_type=authorization_c
ode&code=AUTHORIZATION_CODE &redirect_uri= CALLBACK_URL
7: Client receives Access Token
{"access_token":" ACCESS_TOKEN","token_type":"bearer","expires_in":3872,"
refresh_token":" REFRESH_TOKEN","scope":"read","uid":,"info":{"name":"Peter
Varga","email":"peter.varga@dpc.hu"}}

13. Implicit Flow

14. Implicit Flow (1-3)
1-2: Authorization Request
https://oauthprovider.example.com/oauth/authorize?
response_type=token&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=re
ad
● response_type= token
● client_id=CLIENT_ID
● redirect_uri=CALLBACK_URL
● scope=read
3: User authorizes request
● User authenticates if not authenticated yet

15. Implicit Flow (4-6)
4: Browser is redirected to Client’s CALLBACK_URL
https://sample.oauthclient.com/callback #token=ACCESS_TOKEN
● #token=ACCESS_TOKEN
5: Client loads javascript which will extract token from hash
● The web server does not get access token directly
6: Script extracts Access Token from URL’s hash
● Now the script can share it with the client

16. Access Token
● The access token is a “bearer token”; anyone
presenting it can obtain access:
– The access token is sent through TLS/SSL from the
authorization server to the client
– The access token usually has a short life span and is
renewed through refresh tokens
● A client can query the resource server endpoints to
access resources/information

17. Accessing Resources
● Once in possession of an access token, the client
presents the token to the resource server
● The resource server validates the token, its scope
and its expiry date
● The validation generally requires interaction or
coordination with the authorization server
GET /protected/resource HTTP/1.1
Host: resource.example.com
Authorization: Bearer ACCESS_TOKEN

18. Access Token Information
● The specification does not include the
communication between the resource server and
the authorization server
● There are proprietary mechanisms/implementations
– The authorization server has an endpoint which can be
used to get info about the presented access token
GET /openam/oauth2/tokeninfo HTTP/1.1
Host: login.example.com
Authorization: Bearer ACCESS_TOKEN

19. Bearer Token Recommendations
● Safeguard bearer tokens
● Validate TLS certificate chains
● Always use TLS (https)
● Don’t store bearer tokens in cookies
● Issue short-lived bearer tokens
● Issue scoped bearer tokens
● Don’t pass bearer tokens in URLs

20. OpenID Connect

21. OAuth 2.0 is NOT an Authentication Protocol

22. OpenID Connect
● OpenID connect = Identity, Authentication + OAuth2
● OAuth 2.0 is an authorization protocol; when a
client receives an access token it does not know the
identity of the user
● OpenID Connect leverages the OAuth 2.0
handshake to provide Identity assertion through an
ID token
● With OAuth 2.0 the client requests an access token;
with OpenID Connect the client requests an access
token and an ID token

23. OpenID Connect Flow

24. OpenID Connect Flow (1-3)
1-2: Authorization Request
https://oauthprovider.example.com/oauth/authorize?
response_type=code&client_id= CLIENT_ID&redirect_uri= CALLBACK_URL&scope=ope
nid%20profile
● response_type= code
● client_id=CLIENT_ID
● redirect_uri=CALLBACK_URL
● scope=openid%20profile
3: User authorizes request
● User authenticates if not authenticated yet

25. OpenID Connect Flow (4-7)
4-5: Browser is redirected to Client’s CALLBACK_URL
https://sample.oauthclient.com/callback?code= AUTHORIZATION_CODE
● code=AUTHORIZATION_CODE
6: Client requests Access Token
POST https://www.googleapis.com/oauth2/v3/token
Content-Type: application/x-www-form-urlencoded
client_id=CLIENT_ID&client_secret= CLIENT_SECRET&grant_type=authorization_c
ode&code=AUTHORIZATION_CODE &redirect_uri= CALLBACK_URL
7: Client receives Access Token
{"access_token": "ya29.JgEXH5-koEv0wnizPyikm8qdpRG",
"token_type": "Bearer","expires_in": 3597," id_token":
"eyJhbGciOiJSUzI1NiIsImtpZCI6Ijc0ZWIyNDY1MGE0NzViNDkz.
ZGQzZjFiMjU2MmM5MTZmOTA1MzIyOTAifQ.
eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwic3Vi"}

26. OpenID Connect ID Token
● Signed claim about user identity
● In Standard JSON Web Token (JWT) format
● Client must validate it:
– Signature
– Audience
– Expiry
– Nonce

27. JSON Web Token

28. JSON Web Token
● Compact, URL-safe means of representing
claims to be transferred between two parties
● IETF Standard
– https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-
32
– http://jwt.io/
● Simple Structure:
– Header
– Payload
– Signature

29. JSON Web Token (JWT) Structure

30. User Information Endpoint
● OpenID Connect specifies it
● Retrieves the user info about the current session
represented by the access token
GET /openam/oauth2/userinfo HTTP/1.1
Host: login.example.com
Authorization: Bearer ACCESS_TOKEN
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": "248289761001",
"name": "Jane Doe",
"given_name": "Jane",
"family_name": "Doe",
"email": "janedoe@example.com"
}

31. Demo

32. Starting Implicit Flow with OpenID
Connect

33. Processing Tokens Passed by the
Authorization Server

34. Summary
● OAuth 2.0
● OpenID Connect
● JSON Web Token (JWT)
● Demo
● Q&A

35. Q & A