10 things you should know about OAuth2 and OpenID Connect

09 June 2020

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.

Guidelines for token lifetime

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.

Sender constrained access tokens

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. ;-)

Cédric Boon

Written by Cédric Boon

Post a Comment

Lists by Topic

see all

Posts by Topic

see all