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.
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
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.
The user explicitly wants to revoke the application’s access the user doesn't want to use anymore.
The developer wants to revoke all user tokens for their application.
The developer deleted the application.
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