/Logos/ae-logo-pos-rgb.svg){kind=logo}
As a web security specialist, it’s important to stay on top of the evolutions in the security world. A few weeks ago, we sent ten of our technical consultants to the “Mastering OAuth 2.0 and OpenID Connect” course by security specialist Philippe De Ryck. We'd love to share our top 10 key takeaways with you.
There is only one flow
Forget all OAuth flows. The only one that matters is the ‘Authorization Code Flow with PKCE’ (pronounced ‘pixy’). Use this flow wherever you can, it’s the most secure one for basically all scenario’s (Single Page, classic web and mobile applications).
Bye-bye iframes and cookies
The availability of the ‘Authorization Code Flow with PKCE’ for SPA’s now also enables the use of refresh tokens on the front-end. This is a much better alternative than token renewal using iframes and the IdP SSO cookie (e.g. recent evolutions in third-party cookie blocking might break your application in the future).
Shorter is better
Guidelines for token lifetime: as a general rule, an access token should be refreshed around every 5 to 10 minutes, while refresh tokens could live for around 8 hours.
Spend your time right
There is currently no way to protect security tokens on your front-end application against cross-site scripting attacks. Any XSS vulnerability therefore reduces the security of your authentication strategy to zero. Therefore, focus on your security efforts first and foremost on mitigating cross-site scripting vulnerabilities. (E.g. enable CSP, …)
The best tokens are those that do not exist
If you really care about security: don’t use tokens in your front-end. Instead, use a backend-based token flow and use session cookies for securing your communication between front-end and backend. Cookie security is actually pretty good, and cookies are safe to use in this scenario with regards to third-party cookie blocking.
mTLS for the win
For authentication in a client credential flow, mTLS is generally the best choice.
Reference vs self-contained
There is hardly a case for reference tokens. Self-contained tokens with a short lifespan (5-10 minutes) are good enough in 99% of the cases.
Scopes are not the holy grail
Scopes help to perform authorization on a “feature”-level. However, besides scopes you still have to foresee “object”-level access control. E.g. a “mail:read” scope does not tell whose mail can be read.
Net-level security
The use of ‘sender constrained’ access tokens renders stolen access tokens useless.
Not an exact science
Guidelines for custom claims in access tokens:
- A claim like ‘customerID’ or ‘tenantID’ is certainly useful in an access token.
- A user-specific ‘permissions’ claim should probably not be part of an access token.
- RBAC roles can be ok, but a dedicated authorization service (a ‘policy decision point’) is in many cases a better solution.
Finally, a word of advice on “delegation” scenario’s: if a customer requires it, ask the question “Why do you need it?” at least three times. And implement ‘trusted subsystem’ instead. ;-)
