Search code examples
oauth-2.0

What is the best approach in terms of security when making a request on a resource server that uses Oauth2?

What is the best approach in terms of security when making a request on a resource server that uses Oauth2 ?

With four actors :

  • a JavaScript client
  • a client server which distributes the Javascript client and allows to obtain an Oauth2 token with the Authorization Code process
  • an authentication server
  • a resource server

First approach: Use the client server as a proxy to access the resource server from the Javascript client, and not expose the JWT token.

Second approach: Expose the JWT token and access the resource server directly from the JavaScript client.

Solution

  • 1: JAVASCRIPT ONLY APPROACH

    This is used when you want to follow an SPA architecture, with no web back end and deploying the SPA's static content to a content delivery network. But it has these issues and is no longer really viable:

    • Increased concerns about XSS and threats in the browser
    • Due to recent browser cookie restrictions, user experience and multi-tab browsing only work reliably if you store long lived tokens in local storage, which is bad from a security viewpoint

    2: REFRESH TOKEN IN A COOKIE APPROACH

    A good next step is to store refresh tokens strongly encrypted in an HTTP only secure cookie, with only short lived access tokens in the browser:

    • Silent token renewal works reliably since you do not need to rely on the third party SSO cookie to get a new access token

    This is a pretty secure model, but there are still some concerns about access tokens being intercepted, either at rest or in flight. The main mitigations are to keep access tokens short lived, unreadable and store them only in memory.

    3: NO TOKENS IN THE BROWSER APPROACH

    It is common once you have implemented this option to also use cookies for access tokens, which is currently considered the browser best practice:

    • Use only the most secure SameSite=strict cookies in the browser
    • Fewer concerns around cross site scripting (XSS) vulnerabilities

    Browser exploits to send secure cookies via session hijacking are still possible so it is recommended to also follow best practices to protect against XSS risks.

    SEPARATING WEB AND API CONCERNS

    You can get recommended security and also an SPA architecture by implementing Website security in an API, which is an evolution of the third approach. It is a tricky flow, but if interested, have a look at the Curity resources on this topic: