0

I've spent a few days trying to figure out a secure authentication method for SPA/React (client-side).

Most of the tutorials I've read in the wild contradict each other.

One says have to store in Cookies another in Local Storage, one says don't need to use refresh token, one says have to use a refresh token.

I'm building a React SPA app for the frontend and Express for the API (backend). Both are stored in the same domain:

  • React: example.com
  • Express: api.example.com or example.com/api

Is it enough to secure my application by using Cookie (access token JWT):

  • httpOnly:✅
  • secure: ✅
  • sameSite: strict
  • without refresh token

This matches the answer here: https://stackoverflow.com/a/57779076/11340631

The question is:

  1. Is this safe enough?
  2. How long does it take to set the expiration of the access token?
  3. Is this as per Oauth recommendation?: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps
  4. What if my access token is stolen? For example, my friend is using my PC and he stole my cookies and use it in his PC browser.

I really hope to get the answer here, any answer is appreciated.

R.M. Reza
  • 725
  • 1
  • 8
  • 20

1 Answers1

0
  1. It's safe against extracting the token with Cross Site-Scripting, but, without other security controls it might be prone to Cross Site Request Forgery (cookies are automatically attached to a request). Is API accepting key in the cookie or must it be sent in the Authorization Bearer header?

My concern is, that if you're not using refresh token, the access token must have a relative long expiration. OAuth2 was not intended to be used to authentication alone, but together with some session-like solution, for example OpenID Connect and SSO.

  1. The shorter the better, unless it can be revoked any time server-side. If there's no way to revoke the key, the 5 minutes expiration date is, in my opinion maximum. That's why refresh token and session-like endpoint is the must.

  2. OAuth is not designed for web application client's authentication at all. That's the common anti-pattern in many projects I've pentested. https://oauth.net/articles/authentication/

  3. I'm glad for your awareness of such a threat. Access tokens must either live very shortly, or they must be revoked server-side in a some way, for example by utilizing some kind of revoke-list. Or the refresh token with server-side-like session endpoint should be utilized.

Malipek
  • 196
  • 5