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.
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).
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).
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.
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, …)
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.
For authentication in a client credential flow, mTLS is generally the best choice.
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 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.
The use of ‘sender constrained’ access tokens renders stolen access tokens useless.
Guidelines for custom claims in access tokens:
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. ;-)