According to Google, you can only create 100 refresh tokens per Google account and when you create more, the rest are canceled
Currently, there is a limit of 100 refresh tokens per Google account for each OAuth 2.0 client ID. If the limit is reached, creating a new refresh token automatically invalidates the oldest refresh token without notice. This limit does not apply to service accounts.
In other words, logging in with Google to get customer data and also being able to use other APIs (eg Google Drive) thanks to the refresh token without having to request permissions again isn't useful?
It doesn't work when you plan to have more than 100k users and even more?
This limit is per-user. You can have many thousands of users, but each user can only have at most 100 refresh tokens for this particular client ID.
Related
I am building a Smart Home skill for Alexa, and as part of the skill, I need to use the Login with Amazon OAuth server. I have managed to get to the point of handling the initial authentication of the user by handling the AcceptGrant directive and requesting access tokens from LWA. The problem that I am having is how to uniquely identify the user after the authentication is complete.
Amazon's documentation states the following about uniquely identifying customers:
Store the access and refresh tokens with the grantee access token so that you can always associate the tokens with the customer. Store the tokens in a secured location, such as Amazon Web Services (AWS) DynamoDB or a secure token store in your device cloud.
Source
I have followed this advice and, as part of the authentication process, I use a simple DynamoDB table to store the grantee token as the primary key and the access and refresh tokens as associated with it. Then, when a future request comes in, I use the access token from the directive to look up the user in the table. This works fine until the token expires, at which point, I am no longer able to identify the user, as I cannot find an entry in the database. I understand that I am supposed to renew the token, but how can I do that if I can't find the user for whom I am supposed to perform the renewal in the first place?
I have tried finding a solution in the Amazon developer documentation, but all I have come across is the following, and it is too vague to be helpful:
Once you have the token, verify that it identifies a user in your resource server. The token could become invalid for multiple reasons, for example:
The user deleted or canceled their account with your service. For example, an Alexa user might have set up account linking with My Lights, then later canceled their My Lights account. At this point, the token stored by the Alexa service would identify a non-existent user.
The token has expired, and the Alexa service was unable to obtain a new token. This can occur with an authorization code grant if your authorization server does not provide refresh tokens.
Source
I am using the following curl method to generate the token. But this always return a token which is valid only for 60 mins. I want to increase the expiry of this token (up to 6 hours) using the below method. How can I achieve this?
curl "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=[AUDIENCE]&format=full&licenses=TRUE" \
-H "Metadata-Flavor: Google"
You can't generate a short lived credential from the metadata server. You need to query the Service account credential API. The documentation explains how to do that.
The answer depends on several items:
Is your project part of an ORG?
If no, the answer is you cannot. If yes, modify the constraint constraints/iam.allowServiceAccountCredentialLifetimeExtension Google will fail token create requests for longer than 1 hour without this constraint. Then review the other items in this list.
Are you calling a Google API with the Identity Token?
If yes, the answer is you cannot. Google APIs will reject all tokens with an expiration of more than 1 hour.
Can you create/deploy a service account JSON key file to the instance?
The metadata service cannot be modified. The tokens are preset for one hour. You can use a service account to create OAuth tokens (Access and Identity) valid for up to 12 hours. Refer to item #1 and the link below. On my website, I have articles on how to create OAuth Tokens from service accounts.
Do you have a requirement to only use a Google SDK?
If yes, then the answer is you cannot. You must write code that creates a JWT with a custom payload, sign the JWT using the service account's private key and finally exchange the signed JWT for an OAuth Identity Token. The exchange occurs by calling a Google endpoint.
Are you using the Identity Token to call a service protected by IAP?
For this case, I do not know the answer. I have not attempted to use OAuth tokens with a longer expiration.
Generating an OAuth 2.0 access token
Is there anyway to change the access token timeout in AWS Cognito?
Amazon Cognito User Pools now enables customers to choose how long their access and refresh tokens should be valid. Access tokens can be configured to expire in as little as five minutes or as long as 24 hours. Refresh tokens can be configured to expire in as little as one hour or as long as ten years.
Reference:
08/2020: Cognito Token Expiration
Using Tokens with User Pools - Amazon Cognito
I am trying to add a Google login through Amazon Cognito, I have setup everything needed, I have also configured the attribute mapping from google to my pool attributes, I've mapped 'access_token' attribute to 'google_access_token' attribute and 'refresh_token' to 'google_refresh_token'. When sign in process starts, google prompts me for required permissions needed and redirects back to my app, and I can see on cognito dashboard that user is added with access token mapped in 'google_access_token' but no refresh token there. I double checked every configuration everything seems fine. I also tried mapping other attributes like 'token_type' and 'expires_in' those are getting mapped except the refresh token.
I found out that for generating refresh token from google, client need to pass 'access_type=offline' parameter in the GET parameters which Amazon Cognito DOESNOT send while starting OAUTH login with google, so google doesnt provide google refresh token. So in nutshell there is no way ( Atleast now ) to get refresh token from google and access google APIs "offline" if you are using Amazon cognito. Alternatively I used Auth0 which supports this and can send access_type parameter to google and can store refresh token.
If I may ask, have you seen this document?
Understanding Amazon Cognito user ool oauth 2.0 grants
To get to the point, this concern may be because of the OAuth Flow we have set in the Cognito User Pool. We need to use "Authorization Code Grant" as the OAuth flow. Implicit Grant doesn't generate refresh tokens, but Authorization Code Grant does.
If you're using Amplify framework in your project, this framework will do most of the heavy lifting for you. You just need to setup the User Pool's app client correctly and configure Amplify for that specific app client.
I hope this helps.
I'm looking at my options for a managed sign-on service and AWS Cognito looks promising.
I notice that it's user pools etc do not currently replicate across regions. I wanted to confirm that 1 region is sufficient us-west-# for example (or us-east-#) would be sufficient for an application that has users spread across Canada, the US and Puerto Rico.
In general, not only in the case of Cognito, the closer your users are in the data center that hosts your services the better. And this is only so you can minimize the propagation delays between your clients and the data center hosting your service.
Therefore, if you have to choose one region, choose the one that the majority of your clients are closer to.
AWS Cognito, does not replicate userPools across regions at the moment. Therefore, if you want to use the AccessToken against that userPool you need to go to the region that the userPool resides.
Now, every other service that accepts accessTokens, will accept your token inside AWS, outside AWS in any region.
I'm adding this supplementary detail to the question as a reference for the token types that Cognito returns. As I just found it by googling some of the info in the answer above.
Using the AccessToken against the userPool would be done for things like updating the user's account information. Which would be required to use the region the pool resides in since pools are not replicated.
http://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html
ID Token
The ID token is represented as a JSON Web Key Token (JWT). The token contains claims about the identity of the authenticated user. For example, it includes claims such as name, family_name, phone_number, etc. For more information about standard claims, see the OpenID Connect specification. A client app can use this identity information inside the application. The ID token can also be used to authenticate users against your resource servers or server applications. When an ID token is used outside of the application against your web APIs, you must verify the signature of the ID token before you can trust any claims inside the ID token.
The ID token expires one hour after the user authenticates. You should not process the ID token in your client or web API after it has expired.
Access Token
The access token is also represented as a JSON Web Key Token (JWT). It contains claims about the authenticated user, but unlike the ID token, it does not include all of the user's identity information. The primary purpose of the access token is to authorize operations in the context of the user in the user pool. For example, you can use the access token against Amazon Cognito Identity to update or delete user attributes. The access token can also be used with any of your web APIs to make access control decisions and authorize operations in the context of the user. As with the ID token, you must first verify the signature of the access token in your web APIs before you can trust any claims inside the access token.
The access token expires one hour after the user authenticates. It should not be processed after it has expired.
Refresh Token
The refresh token can only be used against Amazon Cognito to retrieve a new access or ID token.
By default, the refresh token expires 30 days after the user authenticates. When you create an app for your user pool, you can set the app's Refresh token expiration (days) to any value between 1 and 3650.