I am testing keycloak for learning purposes. I am testing the client credentials flow token endpoint to return a jwt for rest api use.
The endpoint returns an access_token and a refresh_token (refresh token is disabled by default unless I enable it in console for the client). I can call the same token endpoint with a refresh token generated from the first client credentials call but it still requires a client secret.
Is it not possible to regenerate an access token in the client credentials flow with just a refresh token?
If not why would I ever bother to pass a grant_type of refresh_token - wouldn't I just call the client_credential flow again since they both require a client secret? I have to guess the answer will be that refresh tokens don't make sense to be used with client_credential flows?
token parameters:
refresh token parameters:
You guess right, refresh tokens don't make sense for the client_credentials grant type. Refresh tokens are used for interactive clients i.e a person. The idea of the refresh token is to remove the requirement for them to have to frequently re-authenticate e.g re-enter their username and password, whilst still allowing the token expiry time to be kept short. The reason you want to keep the expiry time short is that once it is issued it is usually not possible to revoke it. On the other hand if an account has been suspended or the password has been changed and a refresh token has been presented the reissuing of the token can be refused by the identity provider.
As the client credentials flow is used for machine to machine authentication frequently re-authenticating is not a problem. The OAuth RFC specifically states "refresh token SHOULD NOT be included." in the response for the client_credentials grant type.
#James Adcock's answer is right on the spot, aside from a minor detail that I will hopefully clarify with my answer since I have seen this inaccuracy a few times already on stack overflow:
The OAuth2 documentation link states explicitly that "A refresh token SHOULD NOT be included" for client_credentials grant type.
First, one needs to clarify the meaning of "SHOULD NOT" in that context. According to rfc2119:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
As you can read, "SHOULD NOT" does not mean that the specification prohibits it but rather that it does not recommend it.
I have to guess the answer will be that refresh tokens dont make sense to be used with client_credential flows?
As you have seen, the specification does not explicitly prohibits it. Notwithstanding, conceptually, (as already point out by James) it does not make sense to have a refresh token when using the client credentials flow since the backend already has the client secret stored locally anyway, and can simply acquire a new access token without the hassle of either having to store user credentials or request the user to enter them again.
A bit of historical reasoning on why Keycloak allows you to use the refresh token. From this thread of the keycloak mailing list:
Hi,
Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.
To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.
one can infer that the reason why Keycloak had (at that time) the refresh token available (by default) for the client credential flows was to be used as a workaround to a technical issue with their client credential flow implementation (i.e., creating too many sessions).
I have a refresh token in hand, a client_id and a client_secret.
I'd like to determine which end-user the refresh token corresponds to, and/or which scopes.
Is that possible, and, if so, what's the best way to go about that?
Most commonly refresh tokens are opaque unreadable values that map to state stored in the Authorization Server.
Some providers may issue refresh tokens as JWTs, in which case you can read the values. Your code will not be portable though, so this is not advised.
CLIENT
Usually an OAuth client gets a refresh token from the Authorization Server (AS) after user authentication. Later on the client can try to renew access tokens with it.
AUTHORIZATION SERVER
This is the standard component for issuing and renewing refresh tokens and the typical behaviour is like this:
When a user authenticates, record details of the 'delegation' in a database row
Typical fields stored are a SHA256 hash of the refresh token, the user and client IDs, and the issued / expiry times of the grant
This information enables the AS to receive and validate token refresh requests.
ISSUING YOUR OWN REFRESH TOKENS
This should only need to be done if you don't have an AS. In this case follow the AS pattern above. It is recommended instead to use an AS to do it for you though - eg the free edition of Curity from the above link.
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 understand that access tokens are not saved at the server side (usually) and are just verified using some key an algorithm. However, it seems that the normal behavior is to save a refresh token in the server side(i.e:database) and compare it with the user's when the user is trying to refresh their access token. My question is why not just verify the refresh token the same way the access token was verified?
It is generally more secure if a token is an ID that is validated against a database, as this allows the token to be revoked at any time (by removing it from the database or marking it as invalid).
Self-validating tokens, such as JWTs, cannot be revoked (without using a database, which defeats most of the benefits of using self-validating tokens) - they can only expire. Therefore, they should have a short expiry time. The benefit of self-validating tokens is not only performance, but also eliminating dependencies, as the resource server does not need to connect to a database owned by the authorization server. Instead it can simply validate the tokens by itself, using a trusted public key.
Using a database is also easier to implement, as most web apps already have one anyway, and self-validating tokens are easy to do wrong (there are many JWT libraries out there that have flaws or bad defaults).
The refresh token is only used to request a new access token, so performance is not important. The request is sent to the authorization server, which "owns" any authorization-related database(s), so it does not add any unwanted dependencies.
Note that access tokens do not have to be self-validating tokens. It is perfectly fine if they are also simply IDs validated against a database. The separation between access token and refresh token only makes it possible to choose an implementation using self-validating access tokens.
In OpenID Connect an access token has an expiry time. For authorization code flow, this is typically short (eg 20 minutes) after which you use the refresh token to request a new access token.
The ID token also has an expiry time. My question is what is the intent of this?
Any ID token expiry time less than the expiry time of the refresh token will mean you will eventually have an expired ID token, but a valid access token.
So are you meant to:
give your ID token an expiry longer than the refresh token expiry, or
set it to the same expiry as the access token and take some action (what?) when it expires, or
just consume the ID token in your client on receipt, then ignore the expiry time after that?
The OpenID Connect specification just says that when validating an ID token,
"The current time MUST be before the time represented by the exp Claim."
which (possibly) supports the third option above.
EDIT
As OpenID Connect builds on OAuth2 the answer to the supplementary question below can be found in the OAuth2 specification which says,
expires_in
RECOMMENDED. The lifetime in seconds of the access token.
A related question is when you exchange an authorization code for the tokens, the same specification says you might get a response such as:
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbG[...]"
}
But what does "expires_in" relate to in this case? The access token, the refresh token or the ID token?
(For information, IdentityServer3 sets this to the access token expiry time).
I'm answering my own question as have discovered that some of the assumptions behind my question were wrong, so easier to clarify here, rather than re-write the question.
An ID token is meant for proving to a Client that the user has authenticated, and who they are as a result.
When a Client receives an ID token, it will generally do something like convert it to a ClaimsIdentity, and persist this, eg using a cookie.
The ID token has to be un-expired at this point of use (which it should be, since it has just been issued). But after this it is not used again, so it does not matter if it expires while the user still has an active session. The Client has the authentication information it needs, and in turn can choose its own policy for how long the session lasts before the user has to log in again.
My wrong assumption when asking the question was that an ID token and access token should be used together, and therefore both needed to have valid expiry dates. This is wrong for various reasons:
ID tokens are only for authenticating to a Client (as described above).
Access tokens have nothing to do with Clients. They are for access to resources and a Client only handles them if it in turn needs to call an resource.
Something like a standalone MVC or WebForms application only needs an ID token. If it isn't calling an external resource, there is nothing to grant access to, so no access token.
I had to dig into this for my own reasons and wrote it up, so I'll post what I learned here...
First, I'll answer the question at the risk of stating the obvious: The ID token cannot be trusted and its content must be ignored if the current time is greater than the expired time. The questioner's answer states that the after the initial authentication of the user, the ID Token isn't used again. However, since the ID Token is signed by the identity provider, it certainly could be useful at any time to give a way of reliably determining who the user is to other services that an app might be using. Using a simple user ID or email address isn't reliable because it can be easily spoofed (anyone can send an email address or user ID), but since an OIDC ID Token is signed by the Authorization server (which also usually has the benefit of being a third party) it cannot be spoofed and is a much more reliable authentication mechanism.
For example, a mobile app may want to be able to tell a backend service who the user is that is using the app and it may need to do so after the brief period following the initial authentication, at which time the ID Token is expired, and thus, cannot be used to reliably authenticate the user.
Therefore, just like the access token (used for authorization - specifying what permissions the user has) can be refreshed, can you refresh the ID Token (used for authentication - specifying who the user is)? According to the OIDC specification, the answer isn't obvious. In OIDC/OAuth there are three "flows" for getting tokens, The Authorization Code flow, the Implicit flow, and the Hybrid flow (which I'll skip below because it's a variant of the other two).
For the implicit flow in OIDC/OAuth you request the ID Token at the authorization endpoint by redirecting the user in the browser to the Authorization endpoint and including id_token as the value of the response_type request parameter. An Implicit Flow Successful Authentication Response is REQUIRED to include the id_token.
For the Authentication Code flow, the client specifies code as the value of the response_type request parameter when redirecting the user to the authorization endpoint. A successful response includes an authorization code. The client client makes a request to the token endpoint with the authorization code and, according to OIDC Core Section 3.1.3.3 Successful Token Response the response MUST include an ID Token.
So for either flow, that's how you initially get the ID Token, but how do you refresh it? OIDC Section 12: Using Refresh Tokens has the following statement about the Refresh Token Response:
Upon successful validation of the Refresh Token, the response body is the Token Response of Section 3.1.3.3 except that it might not contain an id_token.
It might not contain an ID Token and since there is no way specified to force it to include the ID token, you must assume that the response will not contain the ID Token. So technically there is no specified way to "refresh" an ID Token using a refresh token. Therefore, the only way to get a new ID Token is to re-authorize/authenticate the user by redirecting the user to the authorization endpoint and starting the implicit flow or authentication code flow as described above. The OIDC specification does add a prompt request parameter to the authorization request so the client can request that the authorization server not prompt the user with any UI, but the the redirect still has to happen.
If I understand correctly, according to this and the OpenID Connect Core 1.0 spec, the ID token itself can be stored in cookies as a mechanism to persist sessions, and sent with every authentication-requiring request to the Client. The Client can then verify the ID token either locally or through the Provider's verifier endpoint (if provided, like Google does). If the token is expired, it should make another auth request, except this time with prompt=none in the URL parameter. Also make sure to send the expired ID token in the id_token_hint parameter, otherwise the Provider may return an error.
So, it does seem natural for the ID Token to expire, but prompt=none ensures the new ID token can be obtained smoothly with no user intervention (unless of course the user is logged out of that OpenID).
It is the same intent: you can't use the id_token after it is expired. The main difference is that an id_token is a data structure and you won't need to call any servers or endpoints, as the information is encoded in the token itself. A regular access_token is usually an opaque artifact (like a GUID).
The consumer of the id_token must always verify the (time) validity of it.
I'm not 100% familiar with IS, but I would guess it is a convenience field. You should always check the exp claim.
Expiration is just one of the validations. id_tokens are also digitally signed and that is also a validation you must perform.
Refreshing a token means that you can use it again for requesting something from the authorization server (in this case the OP - the OpenID-Connect Provider) EVEN WHEN THE USER IS NOT LOGGED IN. You typically allow this for limited resources only, and only after the user has logged in and been authenticated at least once. The refresh tokens themselves should be also limited in time.
In OIDC implicit flow you call the Authorization endpoint,
and receive the ID token in the response along with all the scopes and in them all the claims info.
Subsequent calls to an API are meant to be done with code flow.
Implicit flow is meant to enable a javascript only or browser only app. Not an app that is interacting with a server.
So even if there was a way to "refresh" this token, you should not - security wise - allow it to live too long. It will be stolen and reused by unauthorized users impersonating the id. You should force a new login for that.
In code flow you call the OP's Authorization endpoint, and receive an Authorization code (also called an authorization token, or authcode for short). This should expire similar to the id_token that you received in implicit flow, for the same reasons and cannot and should not be renewed.
Your UI or app then call the OP's Token endpoint, and receives (sometimes after the user's further consent through a UI to allow use of their owned resources on the OP's server) both:
An id_token, for authentication - which should never be used again in server calls, except as a hint during logout, when its expiration is not important anymore, and so, for the reasons above should be let to expire, and never be refreshed.
An access_token - which later on, when calling an API, can be given to the OP's UserInfo endpoint. That will return the claims, and the API can authorize accordingly.
You can refresh this access_token, since it only tells the API what claims the user has, and what resources (by scopes and each scope's claims) the user agreed to give you. As explained above this is for allowing access even after the user is not logged in anymore. Of course you never wish to allow the id_token to be refreshed, because you don't want to allow impersonation without logging in.
I wanted to post this answer as a comment but since I haven't been very active on StackOverflow, I guess I'm posting it as an alternate answer.
You also use id_token as the id_token_hint when attempting to log the user out of a session http://openid.net/specs/openid-connect-session-1_0.html. I honestly don't think that it really matters if the id_token is expired at this point since you're only concerned about logging out a particular user.
TLDR;
Validate the ID token before trusting what it says.
More Details
What is intent of ID token expiry time in OpenID Connect?
The intent is to allow the client to validate the ID token, and the client must validate the ID token before operations that use the ID token's information.
From the OpenID Implicit Flow spec:
If any of the validation procedures defined in this document fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used.
To corroborate that, Google's OpenID Connect documentation says this about ID token validation:
One thing that makes ID tokens useful is that fact that you can pass them around different components of your app. These components can use an ID token as a lightweight authentication mechanism authenticating the app and the user. But before you can use the information in the ID token or rely on it as an assertion that the user has authenticated, you must validate it.
So, if our client application is going to take some action based on the content of the ID token, then we must again validate the ID token.
Just share my journey. It's June, 2021. I'm writing this because I've stumbled into 3rd-party authentication business. I'm a veteran programmer but novice to security. In other words, all standards, spec, and terminologies are strangers, anybody can beat me in this field. Forgive me for not going by all the terms.
Cut to chase, I'm writing an Angular/Node app, so UI=Angular, API (API server)=Node/Express. Instead of creating my own Username/Password authentication, I'm turning to 3rd-party authentication, let them validate the genuineness of what the users claim they are. Here are two important guidebooks for me:
Angular Authentication With JSON Web Tokens (JWT): The Complete Guide
Eiji's Authenticate with a backend server
Combining No. 1 and angularx-social-login, I have the UI hooked up with Google, then attach idToken to API, vola! Following No. 2 using local library API can validate idToken, great!
Wait, idToken has exp expires in 1-hour. How do I refresh it?
My understanding is all I need is Google's authentication, I don't care what standard and version they use, but like others I just trust their authentication. Authentication is basically verify who they claim they are. Authorization is access control for what/where users can do/goto. The internal access control (allow users to do what) is not exposed to Google they have no idea of it. So accessToken should be out of the picture. Right?
I've spent days studying on how to refresh idToken now concluded Google does not recommend it nor angularx-social-login offers a way. In No. 2, Eiji has stated clearly:
Hence, solution for my situation is
use Google's authentication.
creates an own session management/timeout-rules at API after initial validation of idToken to mitigate exp.
preferably add this session data into cookie with res.cookie("SESSIONID", myOwnID, {httpOnly:true, secure:true});
For better protection, Eiji also recommends Cross Account Protection. Hope this will help someone!