This document discusses applications and deployment patterns of OAuth and OpenID Connect. It begins with an overview of OAuth 2.0 and OpenID Connect and their purposes. It then examines patterns for how these specifications can be implemented in different application types, including web applications, single page applications, and services. Key points covered include how tokens provide advantages over basic authentication, using the authorization code grant with PKCE for public clients like SPAs, and choosing between ID tokens or access tokens depending on application architecture. The document stresses evaluating use cases before adopting these technologies and how OAuth can help with authorization, reducing credential handling burdens, and providing common APIs.

1. Applications and Deployment Patterns of
OAuth and OpenID Connect
Kavindu Dodanduwa
Senior Software Engineer - WSO2

2. ▪ OAuth 2.0 and OpenID Connect ?
▪ Must known things
▪ Patterns
▪ Q&A
Agenda
2
Theory Practice
Technology

3. ▪ Typical systems with built in login dialog
▪ Maintain its own identities
A decade ago ~ 200X
3
Username :
Password :
Login Cancel

4. Still used ? YES !
4
https://github.com/docker/docker.github.io/issues/6910

5. Samples
5

6. ▪ HTTP - Hypertext Transfer Protocol
▪ Defined through RFC7230 - IETF
Specifications
6
▪ OAuth working group - OAuth 2.0
▪ OpenID Foundation - OpenID Connect

7. ▪ Motivation - Do things better
▪ Specifications - How to do better
Checklist
7

8. ▪ Two different concepts
▪ Authentication - Identify true identity
▪ Authorization - Validate permissions/rights
AuthN and AuthZ
8

9. AuthN and AuthZ
Bob Alice

10. ▪ OAuth 2.0 - RFC6749
▪ For authorization - Access delegation
OAuth 2.0 and OpenID Connect
10
▪ OpenID Connect
▪ End user authentication, built on OAuth 2.0

11. Overview
11
1
2
3

12. ▪ Access delegation
▪ Basic authentication (RFC7617) vs Tokens (RFC6750)
Tokens
12
Authorization : Basic Base64(username:password)
Authorization : Bearer JkP76NNv_sd
▪ Revocable & short life-span

13. ▪ Integrations
▪ Unique login experience
▪ Reduce complexity
Why adopt ?
13

14. ▪ AuthN & AuthZ - General concepts
▪ OAuth 2.0 & OpenID Connect - Specifications
▪ How does it works ? - “Simple as completing few API calls”
▪ Tokens - They have advantage over other mechanisms
Checklist
14

15. Revise
15
User Client Authorization server Resource Server

16. Generic flow
16
Username :
Password :
Login Cancel
1
2
3
4 5
6

17. ▪ Authorization code grant - Official name
▪ Require a user agent - a browser
▪ Browser redirects + backend call
Generic flow
17

18. Public client
18
▪ Public - General availability to customers, users
▪ B2B or B2C
“Such clients cannot protect an embedded secret”[1]
▪ Thus require extra protection when obtaining token!
▪ Avoid access token stealing by other applications

19. ▪ To consume a common APIs/resources - ex: product suite
▪ Identity management
Public client - why OAuth ?
19

20. ▪ Original request contains a hashed secret
▪ Authorization server stores it (against code issue for second step)
▪ Token request contains secret with hash method
PKCE - Proof Key for Code Exchange (RFC7636)
20

21. Public client - PKCE
21
Username :
Password :
Login Cancel
1
2
3
4 5
6

22. ▪ An application which has a front end and a backend
▪ JSP, PHP or ASP are few examples
Web application
22
“Having a backend allows them to securely store secrets”
▪ Usually can store client secrets, tokens securely in a backend
▪ PKCE ?

23. ▪ Identity management
▪ Separate authN logic
▪ Consume common set of
services
Web application - why OAuth ?
23
Client

24. Web application
24
Strategy I
▪ Use OpenID Connect
▪ Authenticate on ID Token
▪ Create a session to maintain
authenticated state
▪ Suitable when there’s tightly
coupled logic (embedded
business logic)
1
2

25. Web application
25
1
2
3
Strategy II
▪ Authenticate and maintain a
session
▪ Store access token against the
session
▪ Consume APIs using access
token
▪ Suitable when logic is
separated from application

26. ▪ Everyone’s favourite
Single Page Application - SPA
26
“They are replacing native applications and web applications”
▪ Runs on the browser
▪ Challenges security implementations

27. ▪ Logic is seperated
▪ Consumes APIs
▪ APIs - Can be easily secured by tokens
▪ Identity management
SPA - why OAuth ?
27

28. SPA - Challenge I
28
1
Where is the backend ???

29. SPA - Challenge II
29
1
Where to store the token ???

30. ▪ Implicit flow - receive access token through URL
▪ Not recommended anymore
▪ Use authorization code grant with PKCE
SPA
30
▪ Cookie vs Local storage
1

31. SPA
31
Username :
Password :
Login Cancel
1
2
3
4

32. SPA
32
Local storage
▪ Not going out of browser
▪ Challenge - XSS
▪ Maintained by JS
Cookie
▪ Set as Secure
▪ Maintained by JS
▪ Challenge - CSRF

33. ▪ No end user involvement
▪ Running in a secure environment
▪ Automation
Services
33

34. “OAuth define a mechanism to obtain tokens and maintain them”
▪ Access token - Safer and Revocable
▪ Credentials issued for client (No end user)
▪ Common interface at API - Share with SPA, Web App and Service
Services - why OAuth ?
34

35. Services
35
▪ Services use client credential grant
1

36. ▪ Bearer tokens (RFC6750)
▪ Token introspection (RFC7662)
▪ Self contained tokens - JSON Web Token (RFC7519)
Protecting your service
36
GET /resource/1 HTTP/1.1
Authorization: Bearer <Token>
Introspect JWT validate

37. ▪ OAuth and OpenID Connect can be used in many application types
▪ Token generation, Identity separation
▪ Reduce burden on credential, authentication handling
▪ Common interface - Protected by tokens
Checklist
37

38. Before you use
38
“Do not use a technology simply because you have heard of it”
▪ Evaluate your use case
▪ Think how your product will evolve

39. Q&A

40. Thank You .!