1

When using a single page application, in what way is access token + refresh token more secure than a single token in a cookie with SameSite: strict. Given the browser supports SameSite.

I completely understand that if you don't have the SameSite setting available that you need an access token and a refresh token. It just doesn't seem obvious why you would need anything else than an access token with en expire time of lets say, a session that holds your token.

Your token either being a JWT or session id.

I assume this question has asked before, at the moment I'm just surrounded by so many contradicting opinions that It's driving me nuts.

Thanks for your time.

0
  1. Introduction

The SameSite Cookie attribute prevents the browser from sending this cookie along with cross-site requests. The main goal is mitigate the risk of cross-site information leakage. It also provides some protection against cross-site request forgery attacks. One of the two possible flags for the SameSite is "strict".

The "strict" flag will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link. Not all browsers implement the attribute "SameSite".

In OAUTH 2.0 both access token and refresh token are defined in RFC6749.

Access tokens are credentials used to access protected resources.
An access token is a string representing an authorization issued to the client.

Refresh tokens are credentials used to obtain access tokens.
Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope.

Access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner.

Issuing a refresh token is optional at the discretion of the authorization server.

If the authorization server issues a refresh token, it is included when issuing an access token.

In the OAUTH 2.0 the token revocation defines a mechanism for clients to indicate to the authorization server that an access token is no longer needed.

This is used to enable a "log out" feature in clients, allowing the authorization server to clean up any security credentials associated with the authorization.

  1. Answer

As written in OAuth 2.0 Security Best Current Practice 4.12

Refresh tokens are a convenient and UX-friendly way to obtain new access tokens after the expiration of older access tokens. Refresh tokens also add to the security of OAuth since they allow the authorization server to issue access tokens with a short lifetime and reduced scope thus reducing the potential impact of access token leakage.

As stated in the answer, the Access Token is more vulnerable then Refresh Token because it is seen by more parties. Resource Server could lead to the leaking of the Access Token, while the Refresh Token would still be safe because Resource Server doesn't see Refresh Token.

There are a few reasons why you might need to revoke an application’s access to a user’s account.

  1. The user explicitly wants to revoke the application’s access the user doesn't want to use anymore.

  2. The developer wants to revoke all user tokens for their application.

  3. The developer deleted the application.

  4. The service provider wants to disable a compromised/malicious application.

These explain OAuth security and vulnerabilities in more detail:

What is going on with OAuth 2.0? And why you should not use it for authentication.

OAuth 2.0 Security Best Current Practice

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.