Say I have three components in a system:
- An identity service, hosted at
- A single page application, served from
- An API, protected by requiring a bearer token signed by
In the single page application, would it be considered secure to keep an access token in memory, and a rotating refresh token (set by
identity.mydomain.com, marked with all the expected security attributes as well as SameSite=strict) in a cookie? The refresh token would rotated similarly to this auth0 article here: https://auth0.com/docs/tokens/concepts/refresh-token-rotation
My thinking for the flow would be as follows:
- User visits
- The SPA sends a request to the
identity.mydomain.comreturns 401 because there is no refresh token cookie
- SPA redirects user to
- User authenticates
identity.mydomain.comsets a refresh token cookie (with HttpOnly, Secure, SameSite=Strict) valid for
- User is redirected back to
app.mydomain.comsends a request to the
identity.mydomain.comreceives the cookie, because it is on the same overall domain.
identity.mydomain.comsets a new refresh token cookie, invalidates the old one, and returns a very short-lived access token
app.mydomain.comcan then store that access token in memory and use it to call the API at
- access token expires, so the SPA sends another request to
identity.mydomain.com/tokento refresh the tokens and the cycle continues.
I can’t see a way this would be particularly vulnerable – the refresh token wouldn’t be available to JS due to its protected attributes, and even if it is retrieved somehow the rotation should ensure it’s not used more than once. The SameSite=true attributes should also protect against CSRF. I’d make the refresh token also a signed JWT so the identity service can validate it and make sure it is issued by the correct authority as well.
If this is insecure, I’ve definitely misunderstood something somewhere down the line – so please could you explain why?