My understanding is that upon successful login Cognito provides my service three tokens for a user, access, ID and refresh. In order to verify a token I'm using jsonwebtoken (jwt.verify(accessToken, pem)). This is all fine, I'm able to verify a token and obtain a new access token with my refresh token if it's expired.
However, my accessToken is valid for one hour. If I want to revoke all of a users tokens using cognitoUser.globalSignOut(), that token will pass my JWT verification using the JWT library for 60 mins as that is all done server side.
Is there a way to send a token to AWS Cognito and ask "Hey is this Token still valid?"
This thread might help you understand how a call to globalSignOut() affects the validity of the 3 tokens.
Is it possible to revoke AWS Cognito IdToken?
Cognito does not have an API to check the validity of the token. You will have to call one of your APIs and check if the call was successful or not.
Related
I'm building a REST API and using AWS Cognito's user pools for authentication. I've got a "get_token" endpoint that returns the JWT access and refresh tokens to the user, which they use to authenticate access to the other REST endpoints provided by the API.
The access token has an expiration timeout. If the user of my API is an application program, what are the best practices for the application to handle when the access token expires? Does the application have to remember the username/password and re-authenticate to continue? Is using the refresh token to get a new access token and use that going forward the best approach?
Is there any documentation, suggestions anyone can point out that might help me out?
Cognito provides 3 types of tokens, id, access and refresh tokens when you login. The way this usually works is that you send either of the first two (depends on whether you want to be sending user payload information to your backend) to your backend via an Authorization header and verify the token there.
Your id and access tokens usually have a shorter expiration time compared to the refresh token. What you should do is, when the id (or access) token expire, you should use the refresh token to generate a new id (or access) token. When the refresh token expires that means that you can no longer generate new id/access tokens from it. In this case, the user (or app) must login again.
I read something like this:
1-Once a user logs in, you can generate a token and store it in MySQL database and share the same token with the response of login API.
2-Store the token using shared-preferences.
3-When a user opens the app, check if the token exists if it does, then send the token with all the APIs inside the request header which requires the user to be logged in.
But what is the point of using token if i was keeping it in database.Eventually this token related with userid and with this userid everthing can be reachable.So I want to ask why should I use some token to keep user loged in instead of user email or something.
Using token is much more secure and useable. Storing just token more secure becase in case of leak, the token can be revoked or something. On the other side storing user's username and password is security risk. Also, most of the services use tokens on their API's and there is no username+pass authorization. For example whole OAuth2 concept is built on top of this. In short, tokens are much more secure and flexible.
Optimal usage of bearer token using as a set with an access token and refresh token. While you are passing access token on header while you are making HTTP request typically access token dies frequently especially when security is a prominent feature of the app, like banking apps. When a user makes an HTTP request and if the access token is dead then you should refresh it via another API call with the refresh token and return the same API call with the new access token.
I'm using Cognito's federated sign in with Sign In With Apple. I have an API Gateway route using a JWT Authorizer through appleid.apple.com From the iOS app, if I pass the identity token to this API Gateway route and it appears to work.
After 10 mins, the Apple identity token expires as expected. Do I have to manually verify a user and fetch a refresh token or does Cognito offer an endpoint to do this for me and return a refresh token?
There is not an ALLOW_REFRESH_TOKEN_AUTH option available.
Cognito offers a refresh token endpoint. When you set up the app client for your userpool in Auth Flows Configuration, the option "ALLOW_REFRESH_TOKEN_AUTH" is already selected by default, then click "save app client changes"
AWS Support said "If you are using Authorization Code grant then refresh token will be generated once the flow is completed. The Authorization code grant flow initiates a code grant flow, which provides an authorization code as the response. This code can be exchanged for access tokens with the TOKEN Endpoint. Because the tokens are never exposed directly to an end user, they are less likely to become compromised." and referenced me here:
https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-user-pool-oauth-2-0-grants/
I am building a serverless react app which uses Cognito for sign-in/sign-out. The app calls API Gateway which is configured to use the Cognito User pool as the custom authorizer.
I also build a lambda function to sign out a user (cognitoIdentityServiceProvider.globalSignOut).
When I sign into the app, and then call the lambda function to perform an admin sign-out, calls to protected API gateway functions from the app are still valid (with Cognito ID token passed in Authorization header);
Are admin calls such as cognitoIdentityServiceProvider.globalSignOut and cognitoIdentityServiceProvider.adminUserGlobalSignOut not realtime, or is API Gateway configured to only validate after an hour?
Just found the answer, unfortunately not what I wanted to hear:
Because IdToken is represented as a JSON Web Key Token, it's signed
with a secret or private/public key pairs, which means even if you
revoke the IdToken, there is no way to revoke the distributed public
key. And IdToken has a short life span, it will expire in a short
time.
Is it possible to revoke AWS Cognito IdToken?
https://github.com/aws/aws-sdk-js/issues/1687
https://github.com/aws/amazon-cognito-identity-js/issues/21
It is the default settings of Cognito user pool. The access token expires one hour after the user authenticates. It should not be processed after it has expired.
You can revoke all user token though using the GlobalSignOut and AdminUserGlobalSignOut APIs. After the user has been signed out:
The user's refresh token cannot be used to get new tokens for the user.
The user's access token cannot be used against the user pools service.
The user must reauthenticate to get new tokens.
An app can use the GlobalSignOut API to allow individual users to sign themselves out from all devices. Typically an app would present this option as a choice, such as Sign out from all devices. The app must call this method with the user's valid, nonexpired, revoked access token. This method cannot be used to allow a user to sign out another user.
An administrator app can use the AdminUserGlobalSignOut API to allow administrators to sign out a user from all devices. The administrator app must call this method with AWS developer credentials and pass the user pool ID and the user's username as parameters. The AdminUserGlobalSignOut API can sign out any user in the user pool.
Please have a look on official documentation:- http://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
I am on the Cognito team. globalSignOut revokes the access token and the refresh token. The id token is a bearer token, that is used with systems external to User Pools. API Gateway will still accept it, but it's validity is of 1 hour.
I need the IdentityServer3 session to expire at the same time as the access token. When the access token expires the user is being redirected to IdSvr it's just automatically issuing new Id and Access tokens. I want to force the user to authenticate again when the access token expires. I'm using the Implicit flow so I don't believe refresh token lifetimes come into play. I'm also using the OIDC-client-JS library.
Your approach doesn't make sense -- what would happen if there were 2 different access tokens?
The better approach is from the client to pass the prompt=login or max_age parameter on the authorization request. See the docs for more info: https://identityserver.github.io/Documentation/docsv2/endpoints/authorization.html