Session vs access token + refresh token

user_225683 0
Viewed 1806

It looks like there are multiple blog posts that are against storing tokens in anyway in the browser (strict no to localstorage/sessionStorage/in-memory variable). The only way suggested is to use server side sessions + HTTPS + httpOnly cookie. So, can below be considered more or less a recommended way?

  1. Use server side sessions + HTTPS + httpOnly + SameSite=Strict cookies for browser based clients (just don't support older browsers at all) + Only support application/json based POST/PUT requests
  2. Use Access tokens + refresh tokens + PKCE for mobile clients
bearer-token access-token oauth-2.0 session cookies
1 Answers

That's pretty much the best practice state of things:

  • A browser client has nowhere secure to store tokens so uses the latest SameSite=strict HTTP only cookies. These can contain tokens if they are strongly encrypted with a key only known to the server.

  • A mobile client cannot easily use cookies, but can use encrypted secure storage to save tokens. Also use the AppAuth pattern and consider the use of https redirect URIs that no malicious app can abuse.

  • APIs receive JWT access tokens and verify them on every request. Note that a reverse proxy can sit in front of APIs to manage decrypting received cookies and forwarding them to APIs, as described in this article.

Of course you should understand the reasoning behind these recommendations. Curity have some articles that provide further info, in case useful:

Also see Guides, since implementing flows correctly and using good libraries are also important factors.

user_90198850
Related