The document discusses the evolution of API security for client-side applications, highlighting the significance of OAuth 2.0 and OpenID Connect as standards for authentication and authorization. It outlines the limitations and vulnerabilities of client-side applications, including token storage issues and potential security threats, while presenting various mitigation strategies. The document emphasizes the importance of secure token management and exploring architectures that enhance security without compromising user experience.

1. The Evolution of API Security for
Client Side Applications
June 30, 2021
johann@wso2.com
Head of Solutions Architecture for IAM @ WSO2
Johann Dilantha Nallathamby

2. Single Page Applications Mobile Applications
2
Client-side Application Technologies

3. Did Client-side Applications
exist before OAuth 2.0?
3

4. While Client-side Applications have existed before the introduction of OpenID
Connect and OAuth 2.0, the advent of OAuth 2.0 and OIDC definitely stirred up a
debate on the right way of performing authentication and API authorization for
Client-side Applications.
OpenID Connect has become the de-facto standard to authenticate users in Client-side
Applications and OAuth 2.0 has become the defacto standard to authorize API
invocations in Client-side Applications.
Client-side Applications can be classified as OAuth 2.0 Public Clients.
Client-side Applications & OAuth 2.0
4

5. 1. They cannot store the client secret completely securely on the client-side
2. They cannot store the access tokens completely securely on the client-side
OAuth 2.0 Public Clients
5

6. Threats and Mitigation Strategies for
OAuth 2.0 Public Clients

7. Threats due to Compromised Credentials/Tokens
7
Client Secret
● Illegal use of
client_credentials grant
flow
● Denial-of-service
attacks on the resource
server
● Impersonation of a
legitimate client
Access Token
● Illegal access of APIs
● Exhaustion of client’s
throttling quota
Refresh Token
● Illegal access of Token
endpoint using
refresh_token grant
flow without client
authentication

8. Mitigation Strategies
8
Client Secret
● Disable
client_credentials grant
flow
● Enforce Redirect URI
registration and strict
validation.
● Provision per-instance
client identifiers for
native applications
(RFC 7591)
● One-time-use client
identifiers / rolling
client identifiers.
Access Token
● One-time-use access
tokens / rolling access
tokens / access token
chaining.
● “Per-user per-client”
throttling limits.
● Heuristic algorithms to
detect token fraud.
Refresh Token
● One-time-use refresh
tokens / rolling refresh
tokens

9. The Evolution

10. Authentication and API Authorization Patterns
10
Authn & API Authz for
CSAs
Back-channel Front-channel
Implicit
Resource Owner
Password Grant
Legacy Authorization Code +
PKCE
Legacy
Authorization
Code

11. Legacy Back-channel Client
11

12. (OIDC-like) Resource Owner Password Grant Client
12

13. Pros
● No hindrance to user experience due
to redirections
Cons
● Standard Single Sign-on experience
mostly not supported
● User passwords are handed to the
application
13
Pros & Cons of Back-channel Flows

14. Legacy Front-channel Client
14
● JavaScript applications
● Cookie-based API authorization
● Session data read from
⦿ DOM on boot when loading the
SPA
⦿ Backend API
⦿ Non “http-only” cookie

15. Legacy Front-channel Client
15
● Cookie-based API authorization
● Session data read from
⦿ DOM on boot when loading the
SPA
⦿ Backend API

16. Implicit Grant Flow
16

17. 17
OAuth 2.0 Client Secret
OAuth 2.0 authorization servers MAY
issue client secrets to public clients
ONLY IF they are unique to each
installation of the application on a
specific device.
Redirect URIs MUST be registered and
verified against the redirect URI in the
authorization request.

18. Pros
● Single round trip (against 2 in
authorization code grant flow)
● Access token returned as a fragment URI
⦿ Doesn’t reach the backend server
component
Cons
● Access token returned as fragment URI
⦿ Visible in the URL address bar
⦿ Stored in the browser’s history
⦿ Browser Sync further increases the
attack surface
● Unverified JavaScript (browser extensions)
reading the access token
● Inadvertent logging of URL at proxy servers
or getting disclosed through referrer
headers
● Token interception attacks
● Access and Refresh tokens are visible by
inspecting the client-side storage
● No refresh tokens 18
Pros & Cons of Implicit Flow

19. Implicit Flow was created due to
an old limitation in the browser
Cross-Origin Resource Sharing
19

20. PKCE
Mitigates Code Interception Attack
20

21. Pros
● All the disadvantages of implicit flow
are negated
● Short-lived and one-time use
authorization codes have reduced
attack surface
● Issues refresh tokens
Cons
● Two round trips (against 1 in implicit
grant flow)
● Access and Refresh tokens are visible by
inspecting the client-side storage
21
Pros & Cons of Authorization Code Flow

22. Pros
● Standard Single Sign-on experience is
mostly supported
● User password are handled only to the
IAM system
Cons
● Redirections hinder user experience
22
Pros & Cons of Front-Channel Flows

23. 23
Improving the Redirection Experience OAuth 2.0 Public Clients
JavaScript Parent/Child Windows or Modals
https://medium.com/@johann_nallathamby/user-experiences-for-iam-on-the-web-2d3
9aa49f388
Store Tokens in Key Chain using Biometrics
● The refresh token is encrypted and stored in the keychain
● Face ID or Touch ID as the default authentication options
to decrypt and retrieve the refresh token
● SMS-OTP as fallback option

24. 1. Thorough audits of source code, knowing exactly which third-party libraries are
being used in the application.
2. Have a strong Content Security Policy (CSP).
3. Most importantly be confident in your ability to build a secure the OAuth 2.0
Public Client.
Developer Challenges in OAuth 2.0 Public Clients
24

25. Securing Tokens at Rest in SPAs

26. 26
Tokens Love Cookies
● Options to store Tokens in OAuth 2.0 public clients:
⦿ HTML5 Web Storage (localStorage and sessionStorage)
⦿ Cookies
● Cookies:
⦿ “httpOnly” - Built in protection against cross-site scripting
(XSS)
⦿ “Secure”
⦿ Support CORS
⦿ Vulnerable to CSRF
⦾ Synchronization Token pattern
⦾ Double-submit Cookie pattern
Cookies are preferred over HTML5 web storage with enough CSRF
protection ensured

27. Is storing Tokens in Cookies
sufficient protection?
● Vulnerable to CSRF
● Violates OAuth 2.0 Bearer Profile
27

28. SPA Security Patterns
28
SPA Security
Non-standard Standard
Sender-constrained
Tokens
Sender-constrained
Tokens (Server)
OAuth 2.0
Client Proxy
Binding Token
Cookie
Split Token
Cookie
Stateless
Stateful
OAuth 2.0
Token Binding
OAuth 2.0 DPoP
RFC 8705

29. 29
Stateful OAuth 2.0 + API Client Proxy
1. Redirect log-in
Request
2. Authorization Code
Grant Flow
3.Redirect log-in
response; session
cookie
3.API Proxy
Request 4. API call
API
Proxy
OAuth 2.0 Server
SPA

30. Pros
● The frontend client is oblivious to the
access token refreshing process.
● Eliminates the need for cross-origin
resource sharing (CORS)
Cons
● Scalability issues due to additional state
in the backend
● Addressing the scalability issue adds
more complexity to the solution
● Nota pure SPA architecture
30
Pros & Cons of Stateful OAuth 2.0 + API Client Proxy

31. 31
Stateless OAuth 2.0 + API Client Proxy
1. Redirect log-in
Request
2. Authorization Code
Grant Flow
3.Redirect log-in
response; cookie -
encrypted tokens
3.API Proxy
Request 4. API call
SPA OAuth 2.0 Server
API
Proxy

32. Pros
● Retains the same advantages as its
stateful counterpart
● No scalability issues as there is no
additional state introduced in the
backend side
● Cannot get hold of the plain-text
tokens and bypass the OAuth 2.0
proxy
Cons
● Still vulnerable to CSRF.
● Not a pure SPA architecture.
32
Pros & Cons of Stateless OAuth 2.0 + API Proxy

33. Pros
● Cannot get hold of the plain-text
tokens and bypass the OAuth 2.0
proxy
Cons
● Still vulnerable to CSRF.
● Not a pure SPA architecture.
33
Pros & Cons of Stateless OAuth 2.0 + API Proxy

34. 34
1. Redirect Authorization
Proxy Request
2. Authorization Code
Grant Flow
3.Redirect Authorization
Proxy Response; bearer
token + cookie
4.API Proxy
Request 5. API call
Inspired by “double-submit cookie”
Split Token Cookie
+
+
SPA
API
OAuth 2.0 Server
Reverse Proxy

35. JSON Web Token (JWT) as OAuth 2.0 Bearer Access Tokens
https://medium.com/@johann_nallathamby/json-web-tokens-jwt-as-oauth-2-0-bearer-a
ccess-tokens-89120c94c082
35
How to Split the OAuth 2.0 Access Token?
Cookie
Bearer Token

36. 36
1. Redirect Authorization
Proxy Request
2. Authorization Code
Grant Flow
3.Redirect Authorization
Proxy Response; bearer
token + cookie
4.API Proxy
Request 5. API call
Binding Token Cookie
Generate a “binding” token and include its hash form in the bearer token
+
+
SPA Reverse Proxy OAuth 2.0 Server
API

37. 37
Web Workers

38. 38
1 OAuth 2.0 Token Binding
● Extends from Token Binding for
HTTP (RFC 8473)
● Suffered an important setback
when major vendors dropped
support for it
2 OAuth 2.0 Mutual-TLS Client
Authentication and Certificate-Bound
Access Tokens
● OAuth 2.0 Clients authenticate
using Mutual TLS
● Tokens bound to client
certificate
● More details to iron out
particularly in terms of browser
experience
3 OAuth 2.0 Demonstration of
Proof-of-Possession at the
Application Layer (DPoP)
● A client uses a DPoP proof JWT
to prove the possession of a
private key belonging to a
certain public key.
Standard Sender-constrained Token Patterns

39. 39
Sliding Sessions
Renew access tokens in SPAs without using refresh tokens or compromising user
experience.
1. Logged-in Session
2. Periodic requests until the
user is active in the SPA
3. Hidden iframe
5. Pass result to a callback
function of the parent window
4. OAuth 2.0 Authorization
Request; prompt=none
6. {Authorization code exchange}
OR {Sign-out and sign-in}
DECISION

40. OAuth 2.0 for Mobile Native Applications

41. The Evolution of OAuth 2.0 for Mobile Native Applications
41
Web View
● Embeddable browser
● Browser security sandbox is
inapplicable
● JavaScript can call system
APIs.
● No standard Single Sign-on
experience
Authorization Server Agent on
Mobile Device
● Single sign-on experience
● Manages API tokens
● Native Applications Single
Sign-On (NAPPS)
WebView Login

42. 42
RFC 8252 - OAuth 2.0 for
Native Apps
● Redirect through external
user-agents only
● App-claimed "https"
scheme redirect URIs
recommended.
● Use “state” parameter to
mitigate CSRF over
inter-app URI
communication channels.
● Web Controllers -
ASWebAuthenticationSes
sion, Custom Tabs
The Evolution of OAuth 2.0 for Mobile Native Applications
System Browser Login

43. References

44. 44
References
1. https://medium.com/@johann_nallathamby/a-primer-on-oauth-2-0-for-client-side
-applications-part-1-46072e3023d8
2. https://medium.com/@johann_nallathamby/a-primer-on-oauth-2-0-for-client-side
-applications-part-2-c234d0adb608
3. https://medium.com/@johann_nallathamby/a-primer-on-oauth-2-0-for-client-side
-applications-part-3-e1f0b56d4e07
4. https://medium.com/@johann_nallathamby/a-primer-on-oauth-2-0-for-client-side
-applications-part-4-be07e55fca64

45. Closing Remarks

46. Unfortunately, “bulletproof” security in Client-side
Applications DOES NOT EXIST!!
Protect against common types of attacks
Reduce the overall attack surface
The RIGHT solution for you depends on your application
requirements, BUT always consider moving away from a
browser storage design to a Backend-For-Frontend (BFF).
one,.

47. THANK YOU
wso2.com