I understand the benefit that if we use a refresh token, the requests containing credentials or refresh tokens are reduced hugely because a client to do some meaningful job in our services can send numerous requests during a period stipulated by an access token. For example, I can send 100 requests in 5 minutes once I attain an access token. Those 100 requests do not contain my credentials, so the security has increased.
My question is what are the benefits of using refresh tokens instead of username and password pair?
I've read many answers and articles about this but they cannot go beyond reiterating that we don't have to expose our credentials through refresh tokens. But who cares about the credentials as long as I got the refresh token? I might as well send my username and password to get a new access token. It effectively supplants the credentials for authentication.
A refresh token still only has restricted privileges, scoped to the client application. It allows you to get new access tokens with privileges (scopes and claims) the app needs, for the lifetime of the user session.
Example properties might be as follows:
Refresh token lifetime: 4 hours
Access token lifetime: 30 minutes
Access token scopes: orders_write benefits_read
subject claim: user123
subscription_level claim: silver
When access tokens are played against APIs, the API's authorization logic restricts logic based on scopes and claims in the token. Eg the user can only access their own orders or benefits their subscription level allows.
Whereas a user's credentials might be usable across many apps, some of which have more sensitive privileges.
Related
There are oauth2 server and some services.
Some user has authorized on computer in 2 services and get 2 access_tokens. And this user has authorized on mobile in some service and get another access_token.
User logout on computer from all services. Logout must invalidate all access_token from this session (computer): tokens 123, 789.
How correct bind access_token and user session?
OAuth2 server has web frontend and remember user by JWT token in cookie. Is it normal bind access_token with this JWT token, and where user click Logout in oAuth2 server, than get all access_token, tied with such JWT token and invalidate them?
The general mechanism works like this:
Access tokens are short lived ~ 60 minutes
They are issued to 'clients' - usually UIs / apps
When you log out of a client you remove its access tokens
This does not remove tokens from other clients on the same computer
But the access tokens used by the other clients will expire soon and the user will need to login again
See also my recent answer and the performance impact of services needing to check access token validity on every single request.
It is worth thinking about what the real concern / requirement is here. Sometimes opinions are based on how older / standalone solutions worked, but there can be a large cost to trying to implement the same thing in an OAuth architecture.
I am looking at implemented Cognito for user login and would like to understand the process of validating JWT's a little better.
The application in question is on asp.net 4.5 MVC and not related to .NET Core. The only information on AWS Cognito I can find online relates to .NET core.
I understand the meaning of each token type as documented here:
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html#amazon-cognito-user-pools-using-the-id-token
I also understand the required steps in validating a JWT:
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html
My question is which JWT needs to be validated and at what stage?
Example 1.
A user logs in, once logged in they are returned with an Access, ID and Refresh token.
Do all of the tokens need to be validated at this point or just the Access token?
Is the refresh token only validated before trying to use it (in order to gain new access and ID tokens)?
OR should all tokens be validated on any authorised content request?
What tokens should be stored in the FormsAuthentication Cookie for use later? We are using the standard [Authorize] pattern in asp.net.
Question: Do all of the tokens need to be validated at this point or just the Access token?
Answer:
Validation is always done on Access token only.
Refresh token itself need not be validated. It is merely used for the purpose of obtaining fresh set of ID token and Access token.
Question: What tokens should be stored in the FormsAuthentication Cookie for use later?
Answer: This is specific to implementation. There is no rule on what token must be saved.
If the requirement is to just know the user's email or phone number, then just the ID token can be saved.
If the requirement is to allow one-time access for up an hour for the user,
then storing just the access token is sufficient.
If the requirement is to allow user to access the resource for up to 30 days, without being prompted for password, then refresh token must be saved.
The recommended approach is to validate the access token as it includes both authentication and authorization. You should be validating access token prior to providing access to protected resources.
The id token contains claims (information) of the authenticated user. It can be used for verification as well but there is more power in using access tokens as you can create scopes to define permissions and roles. Access token is also the input to many of Cognito APIs user operations.
AWS Cognito follows OpenID Connect Protocol which is built on top of Oauth2 for which these terminologies originate from.
The refresh token is a long lived token to retrieve newer short lived tokens (id token, access token). Currently with Cognito's implementation, shorter lived tokens expire every 1 hour and refresh tokens are configurable in the user pool. In the case where a refresh token becomes invalid/expired, attempts to retrieve newer short lived tokens will fail therefore you do not need to validate refresh token yourself.
You can store the refresh token (in some sort of session) to assist with the retrieval of new access, id tokens without re-authentication. You can also store the access token so that the refresh token is used only once per hour (when the access token expires) to prevent issuance of unnecessary tokens and round-trips to Cognito. The id token storage is really up to your use case, if you were interested in keeping the user claims (user information stored in the JWT of id token).
I tried to add YouTube Video from the third party and After one day, I got the success in doing so. But While uploading a video the access token is required and in order to get that access token the user must be logged in. And the expiration time for that access token is 3600 seconds( 1 hr).
Now, There are some of my questions regarding this.
Is there anyway, by which I can refresh access token.
If some one has G Suite account, then Is there any special values for expiration time, or it remains the same?
As per the documentation, I can have maximum 50 tokens, So is there any alternative for it, So that I can get valid token after 50 requests.
To answer your question for number 1, you can check the documentation here.
Access tokens periodically expire. You can refresh an access token
without prompting the user for permission (including when the user is
not present) if you requested offline access to the scopes associated
with the token.
If you use a Google API Client Library, the client object refreshes the access token as needed as long as you configure that
object for offline access.
If you are not using a client library, you need to set the access_type HTTP query parameter to offline when redirecting the
user to Google's OAuth 2.0 server. In that case, Google's
authorization server returns a refresh token when you exchange an
authorization code for an access token. Then, if the access token
expires (or at any other time), you can use a refresh token to obtain
a new access token.
Requesting offline access is a requirement for any application that
needs to access a Google API when the user is not present. For
example, an app that performs backup services or executes actions at
predetermined times needs to be able to refresh its access token when
the user is not present. The default style of access is called online.
About the G Suite account, it was stated 24 Hours in the documentation. Note:
In this SO post answer, the function of Access Token and Refresh Token was discussed.
I am not sure if there are ways to alter the limits because of security reasons.
To clearly differentiate these two tokens and avoid getting mixed up,
here are their functions given in The OAuth 2.0 Authorization
Framework:
Access Tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The
client uses the access token to access the protected resources hosted
by the resource server.
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.
I have two clients, one Public Client used by regular end-users logging in via our web page or native apps and one Confidential Client for our admin system. Both issues two JWT's, one Access Token and one Refresh Token.
The Public Client is not allowed to issue admin rights. The Access Token is short lived, and the Refresh Token has infinite life span.
The Confidential Client is allowed to issue admin scopes. The Access Token is short lived, and the Refresh Token lives 24 hrs.
Is it possible, using Spring Security and their oAuth2 implementation, to downgrade the admin user once the refresh token is expired? That is, once the user have been logged in for 24hrs, the user is not totally logged out, but on the next login he gets two new JWT's, one Access Token for regular user access and one matching Refresh Token for that access level. I guess I'm looking for some kind of hook in the Spring Security framework that allows me to handle token expiration in a customised way.
There's a sentence on your question that confuses me a bit, but I wanted to elaborate on other aspects so this did not fit in a comment.
... the user is not totally logged out, but on the next login he gets two new JWT's, one Access Token for regular user access and one matching Refresh Token for that access level.
What do you exactly mean with on the next login? My confusion here is that if the objective is not to logout the user, then there won't be a next login. I guess this could mean that almost to the end of the refresh token expiration you would want to do your downgrade request and use the still valid refresh token to get a new pair of tokens with less permissions.
According to the OAuth specification you can perform a refresh token request and ask the server for an access token that has less scopes than the one you currently have. However, it also dictates that if a new refresh token is returned, then that token needs to have the exact same scope as the refresh token included in the request.
Personally, for this scenario I would consider instead of downgrading tokens just ensure that in order to perform any administrator related operation the user must be an administrator and actually provided his credentials in the last 24 hours. You could accomplish this by tracking the date and time a given user actually performed a login (by providing their credentials) and then authorize administrator actions based on that value. This way you can increase the lifetime of refresh tokens for the confidential client and only force the administrators to login again if they want to perform a privileged tasks and their current tokens aren't fresh enough.
Finally, still on the subject of refresh tokens (with focus on the security considerations section)... when you say web app for the public client I'm assuming it's a browser-based Javascript application. If this is correct it's generally not recommended to use refresh tokens for these applications because refresh tokens are usually long-lived (in your case they seem to never expire) and the browser cannot ensure secure storage for them. This increases the likelihood of them leaking which would give an attacker access to the application for the lifetime of the token. You may have other constraints that make this security consideration not applicable, but I wanted to call your attention to it nonetheless.
I am just getting started working with Google API and OAuth2. When the client authorizes my app I am given a "refresh token" and a short lived "access token". Now every time the access token expires, I can POST my refresh token to Google and they will give me a new access token.
My question is what is the purpose of the access token expiring? Why can't there just be a long lasting access token instead of the refresh token?
Also, does the refresh token expire?
See Using OAuth 2.0 to Access Google APIs for more info on Google OAuth2 workflow.
This is very much implementation specific, but the general idea is to allow providers to issue short term access tokens with long term refresh tokens. Why?
Many providers support bearer tokens which are very weak security-wise. By making them short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token.
Large scale deployment don't want to perform a database lookup every API call, so instead they issue self-encoded access token which can be verified by decryption. However, this also means there is no way to revoke these tokens so they are issued for a short time and must be refreshed.
The refresh token requires client authentication which makes it stronger. Unlike the above access tokens, it is usually implemented with a database lookup.
A couple of scenarios might help illustrate the purpose of access and refresh tokens and the engineering trade-offs in designing an oauth2 (or any other auth) system:
Web app scenario
In the web app scenario you have a couple of options:
if you have your own session management, store both the access_token and refresh_token against your session id in session state on your session state service. When a page is requested by the user that requires you to access the resource use the access_token and if the access_token has expired use the refresh_token to get the new one.
Let's imagine that someone manages to hijack your session. The only thing that is possible is to request your pages.
if you don't have session management, put the access_token in a cookie and use that as a session. Then, whenever the user requests pages from your web server send up the access_token. Your app server could refresh the access_token if need be.
Comparing 1 and 2:
In 1, access_token and refresh_token only travel over the wire on the way between the authorzation server (google in your case) and your app server. This would be done on a secure channel. A hacker could hijack the session but they would only be able to interact with your web app. In 2, the hacker could take the access_token away and form their own requests to the resources that the user has granted access to. Even if the hacker gets a hold of the access_token they will only have a short window in which they can access the resources.
Either way the refresh_token and clientid/secret are only known to the server making it impossible from the web browser to obtain long term access.
Let's imagine you are implementing oauth2 and set a long timeout on the access token:
In 1) There's not much difference here between a short and long access token since it's hidden in the app server. In 2) someone could get the access_token in the browser and then use it to directly access the user's resources for a long time.
Mobile scenario
On the mobile, there are a couple of scenarios that I know of:
Store clientid/secret on the device and have the device orchestrate obtaining access to the user's resources.
Use a backend app server to hold the clientid/secret and have it do the orchestration. Use the access_token as a kind of session key and pass it between the client and the app server.
Comparing 1 and 2
In 1) Once you have clientid/secret on the device they aren't secret any more. Anyone can decompile and then start acting as though they are you, with the permission of the user of course. The access_token and refresh_token are also in memory and could be accessed on a compromised device which means someone could act as your app without the user giving their credentials. In this scenario the length of the access_token makes no difference to the hackability since refresh_token is in the same place as access_token. In 2) the clientid/secret nor the refresh token are compromised. Here the length of the access_token expiry determines how long a hacker could access the users resources, should they get hold of it.
Expiry lengths
Here it depends upon what you're securing with your auth system as to how long your access_token expiry should be. If it's something particularly valuable to the user it should be short. Something less valuable, it can be longer.
Some people like google don't expire the refresh_token. Some like stackflow do. The decision on the expiry is a trade-off between user ease and security. The length of the refresh token is related to the user return length, i.e. set the refresh to how often the user returns to your app. If the refresh token doesn't expire the only way they are revoked is with an explicit revoke. Normally, a log on wouldn't revoke.
Hope that rather length post is useful.
In addition to the other responses:
Once obtained, Access Tokens are typically sent along with every request from Clients to protected Resource Servers. This induce a risk for access token stealing and replay (assuming of course that access tokens are of type "Bearer" (as defined in the initial RFC6750).
Examples of those risks, in real life:
Resource Servers generally are distributed application servers and typically have lower security levels compared to Authorization Servers (lower SSL/TLS config, less hardening, etc.). Authorization Servers on the other hand are usually considered as critical Security infrastructure and are subject to more severe hardening.
Access Tokens may show up in HTTP traces, logs, etc. that are collected legitimately for diagnostic purposes on the Resource Servers or clients. Those traces can be exchanged over public or semi-public places (bug tracers, service-desk, etc.).
Backend RS applications can be outsourced to more or less trustworthy third-parties.
The Refresh Token, on the other hand, is typically transmitted only twice over the wires, and always between the client and the Authorization Server: once when obtained by client, and once when used by client during refresh (effectively "expiring" the previous refresh token). This is a drastically limited opportunity for interception and replay.
Last thought, Refresh Tokens offer very little protection, if any, against compromised clients.
It is essentially a security measure. If your app is compromised, the attacker will only have access to the short-lived access token and no way to generate a new one.
Refresh tokens also expire but they are supposed to live much longer than the access token.
I've written a little about this because I was pondering the reasoning myself today.
https://blog.mukunda.com/cat/2023/refreshing-access-tokens.txt
Essentially, I think the main security boost is only there if the refresh token does not remain the same over its lifetime.
Let's say someone steals your tokens from your browser cookies because they had access to your device temporarily.
If they use the refresh token, and the refresh token changes, then you have feedback – you are logged out. That can seem rightfully suspicious to careful users who can then take action and revoke all tokens.
If the refresh token doesn't update upon each use, then it is harder to notice that someone has access in tandem. (Chances are, if does update, then it might update from your device automatically before the attacker can even get to use it.)
If the refresh token does not get updated each time you use it, then I don't see any boost in security from the strategy, since it will be right next to the access token and client secrets.
So, why access tokens? It is so you can check that your credentials are valid regularly.
Do refresh tokens expire? Yes, but usually after a few months if you have "remember me" ticked. There's no expiration time in the spec, so you just go until it fails. Services that require longer unmonitored sessions might have secret credentials so they can refresh their refresh token.
Update:
I also glossed through the OAuth 2.0 specification and see the same reasoning, though it emphasizes that the invalid authentication feedback can be caught on the server side. That is a great point – the server can automate revoking the token if it is compromised.
If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach.