The document covers the topics of OAuth 2.0, OpenID Connect, and JSON Web Tokens (JWT), outlining their functionalities in authorizing and authenticating users. OAuth 2.0 presents methods for secure resource access via tokens while addressing common security issues. OpenID Connect builds on OAuth 2.0 to provide user identity verification through an ID token, and the document also includes flow diagrams and practical implementation details.

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