Currently in Keycloak, Access Token Lifespan is configurable and there is no way to configure lifespan for ID Token. How do I configure a lifespan value for ID Token?
Currently in Keycloak, lifespan for ID Token is the same as Access Token Lifespan.
Please refer to the code:
https://github.com/keycloak/keycloak/blob/8.0.0/services/src/main/java/org/keycloak/protocol/oidc/TokenManager.java#L765
Shouldn't be different ?
From Auth0 https://auth0.com/docs/tokens/id-tokens - ID Tokens are used in token-based authentication to cache user profile information and provide it to a client application, thereby providing better performance and experience. The application receives an ID Token after a user successfully authenticates, then consumes the ID Token and extracts user information from it, which it can then use to personalize the user's experience.
Here are some references which I could gather
https://auth0.com/docs/api-auth/why-use-access-tokens-to-secure-apis
https://www.ory.sh/docs/hydra/configuration
https://auth0.com/docs/dashboard/guides/applications/update-token-lifetime
Related
For refresh token rotation and update both refresh token and access token way, I am wondering, for the same user, if he or she opens different browser and logs in. This means, for the same user, tokens rotation would think it is stolen. Am I right?
If I don't want this to happen, can I use IP combined with user ID to identity the user? Is it secure? I know if it is shared IP, then no.
Is there anything that hacker cannot fake which can distinguish hacker and the user? I think Phone has its device ID of some sort. How about browser?
I think you are confusing completely different concepts
Oauth - authorization.
Open id connect - sign-in - authentication.
Access tokens and refresh tokens are used for authorization. A user grants your application access to their data. The user does not have to be present for this to happen. There for using an access token to prove a users identity is not the correct course of action.
You should use open id connect, to authencation a user - sign them in. Then you should get an id token back which contains claims, one of these claims is the subject claim which should be the users id on the system you are connecting to. You should use that to identify the user.
As for hacking oauth. (Authorization)
Access tokens are short lived they will give your application access to a system for a limited amount of time usually an hour. If a hacker got the access token they would also have access to the system for this hour. access tokens are self contained. no further verification is preformed.
Refresh tokens require the client id and client secrete in order to request a new access token. So the hacker would need to have your client id, client secret, be on one of the valid redirect uris. in order to request a new access token. This is why you should not set a redirect uri to localhost.
Hacking and open id connect.(authencation)
Well as far as signin goes the hacker would need to have the users login and password in order to signin in and get an id token back. You should be good to assume that this is not a hacker and is the user behind the machine.
I'm researching to use OIDC for SSO (Single Sign On).
I know OIDC flow always return id_token and access_token but I don't know why we need id_token?
As I know id_token used only by client application to get authenticated user information. Client application will decode and verify JWT then extract user information from it.
But because I have access_token, I can use it to get user information from endpoint /userinfo. So I dont't need id_token?
Please help me understand the right way to use id_token.
You are correct that you can get the user details using the access token from the /userinfo endpoint.
The ID-token represents details about the user and more important how the user authenticated (password, 2FA...). The lifetime of the Id-token is often very short (like a few minutes).
Just like how the specification describes it:
The ID Token is a security token that contains Claims about the Authentication of an End-User by an Authorization Server when using a Client, and potentially other requested Claims.
I am not clear on what exactly I should do with the id token from Google after the initial verification.
I'm developing on expo/react native and get the id token locally. Then, I send it to my server and verify it using google client libraries. Once it's verified what should I do with it?
Ideally I could use it to protect my api routes (express) but id tokens expire after 1 hour and I'm not sure how to refresh them with the client library. So, I don't know how I would do this.
Is that the intended use for id tokens? Should I instead be signing my own jwt and sending that back to the client? Then, the client could send that in the auth header of each request to a protected routes.
Google says:
After you have verified the token, check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
https://developers.google.com/identity/sign-in/ios/backend-auth
Do I use the id token to "establish a session for the user"?
Yes, the ID-token is only used to create the local session, perhaps also create a local entry in your local database if that is used.
The ID token also have a very short lifetime, like 5 minutes in some systems. So it has no long-term use.
The ID token is intended to authenticate the user. It gives you information about the authenticated user, it should not be used to allow access to your endpoints. Access tokens or sessions are intended to do so. So in your case, you should do exactly as your gut feeling tells you - create a session for the user basing on the data you got in the ID token.
If you have your own Authorization Server you can use the ID token to issue an access token and return the token to the frontend app, then use the access token to access your backends. Have a look at OAuth flows if you would want to go this way.
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'm considering to use id token instead of id token for authorization, so that resource servers can validate its sign and extract user id out of it. Is there any dowside to this method which I'm not aware of?
I guess I cannot use verify endpoint if I throw away access token. For us, it doesn't matter which scope the user granted access to since both client app and OIDC's identity provider is owned by us.
I'm using this library to implement an OAuth2 and OpenID server.
https://github.com/bshaffer/oauth2-server-php
Usage of ID Token is intended for the client application. Client uses it to authenticate the end user. All this is made possible through claims ID Token transfer. And these claims are built into an JWT. In simple terms, ID Token is a self-contained token.
Now, sharing of ID Token outside of client is okay if you control all intended parties. Think about a scenario in which you leak sensitive user information through ID Token. For example if ID Token contain a claim about gender which only intended for client to use. But when you share ID Token with a third party, you expose those sensitive information. It could be a crime if there are legal barriers.
Another point is on ID Token validation. Hence ID Token targets the client, important claims such as aud is set accordingly. When you pass ID Token to a backend to be used, such validation could fail.
There are two solutions. First is to use self contained access tokens. These days it is common to use JWT based access tokens. With them, you get the same solution. It will contain end user identity, scope values as well as token validation information. Azure AD use such approach - check this link.
Second one is to use ID Token. Given that you control both front end and backend, my opinion is you are okay to use it. But be mindful about future extensions. Specially not to expose it to other parties.