We use the googleapis for our web app and store and manage the access token and refresh token to our database.
When we refresh the access token of users using refresh token, rarely we had the GaxiosError: invalid_grant.
Now, we use the google api nodejs client[ https://github.com/googleapis/google-api-nodejs-client ].
We store the access token and the refresh token to our database for each user and they are updated by bellow logic per 6 hours.
import { google } from 'googleapis';
// create oauth2client for google apis
const oAuth2Client = new google.auth.OAuth2(client_secret, client_id, redirect_uri);
// set current access token and refresh token (==current_tokens)
oAuth2Client.setCredentials(current_tokens);
// refresh access token and refresh token
// new_token contains access_token and refresh_token
const new_token = await oAuth2Client.refreshAccessToken();
// store the new access token and new refresh token to database
...
Does anyone know what may be causing GaxiosError: invalid_grant?
I'm getting the feeling that it may be due to the refresh token being updated every 6 hours.
Additional Info
the setting of generating auth url
const authUrl = oAuth2Client.generateAuthUrl({
access_type: 'offline',
scope: GOOGLE_APIS_SCOPE, // GOOGLE_APIS_SCOPE contains scopes
prompt: 'consent',
});
There are a number of reasons why a refresh token will expire If we check the documentation for Oauth2 You will find a list of them here.
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
The user belongs to a Google Cloud Platform organization that has session control - policies in effect.
A Google Cloud Platform project with an OAuth consent screen configured for an external user type and a publishing status of "Testing" is issued a refresh token expiring in 7 days.
Currently the most common reason would be that your application is not set to production if its still in testing then your refresh token will expire in a week.
You mention that its stored in the database every six hours. I would double check if you are refreshing the access token every six hours and that it does return a new refresh token each time that you are in fact updating the database with the most current refresh token otherwise you may be reaching the "maximum number of granted (live) refresh tokens"
Related
When a user logs out of Azure B2C using the MSAL library on a mobile device this only clears the local cache. The remote session on the server still exists which means any existing refresh tokens could still be used.
From searching I know that the Microsoft Graph API can be used to revoke the current user's sign in session, and therefore invalidate all current refresh tokens. I believe I am doing this, but the refresh tokens keep remaining active.
Here is my flow:
I get a token for user A (I tried this with auth code flow and ROPC but I don't believe that should make a differnce).
I confirmed that I can get a new access token by using the current refresh token that is returned in a Postman call -
{{b2c_login_url}}/B2C_1_ROPC_SignIn/oauth2/v2.0/token?grant_type=refresh_token&client_id={{b2c_ropc_client_id}}&refresh_token=xxxxx&scope={{b2c_scopes}}&redirect_uri={{b2c_api_redirect_uri}}
This returns a new access token as expected.
I then take the azure userId value ("oid" property in the access token) and pass that through to my API that then runs the following code.
var graphClient = GetGraphClient();
var result = await graphClient.Users["{" + userId + "}"]
.RevokeSignInSessions()
.Request()
.PostAsync();
return result.GetValueOrDefault();
I can see that the result of this expression is true. I can also go onto the Azure B2C user details and see that "StsRefreshTokensValidFrom" has been updated to the current date time as expected.
Now, I run the exact same http request I ran previously using the refresh token to get another access token, but this time, it should fail. However, I continue to get new access tokens.
The strange thing is that I am sure I tested this previously, tried to get a new token, and it failed as I'd expect. But now it will always return me new tokens.
I feel I am missing something here. Any advice?
I tried to reproduce the same in my environment and got below results:
I generated token for a B2C user using ROPC flow via Postman with parameters as below:
POST https://<tenant_name>.b2clogin.com/<tenant_name>.onmicrosoft.com/<policy>/oauth2/v2.0/token
client_id : xxxxx-xxxx-xxxx-xxxxxxxx
grant_type : password
scope : https://<tenant_name>.onmicrosoft.com/web_api/api.read offline_access
username : b2c_username
password : password
Response:
Using the above refresh token, I'm able to generate access token successfully like below:
POST https://<tenant_name>.b2clogin.com/<tenant_name>.onmicrosoft.com/<policy>/oauth2/v2.0/token
client_id : xxxxx-xxxx-xxxx-xxxxxxxx
grant_type:refresh_token
scope:https://<tenant_name>.onmicrosoft.com/web_api/api.read
redirect_uri:https://jwt.ms
refresh_token:paste_refresh_token
Response:
To revoke refresh tokens, I ran below query via Graph Explorer like this:
POST https://graph.microsoft.com/beta/users/<user_id>/invalidateAllRefreshTokens
Response:
Code Sample in C#:
GraphServiceClient graphClient = new GraphServiceClient( authProvider );
await graphClient.Users["userid"]
.InvalidateAllRefreshTokens()
.Request()
.PostAsync();
To confirm that, I checked user's details in Portal like below:
When I tried to get access token with same refresh token, I got error saying token is revoked like below:
After revoking the tokens from Graph API, it may take up to 5 minutes to work.
If you run the query for access token as soon as you revoked the refresh tokens, you may still get access token.
So, wait for 5-10 minutes and try to get the access token with same query. Then, you won't be getting access token as the refresh token will be revoked at that time.
I'm building a Node.js API service. I'm issuing a JWT access token that expires every 5 minutes, a refresh token that expires in a month, and /fetch-access route to get a new access token when called from the SPA/client.
Now I'm using a database to store a list of recently revoked refresh tokens that an administrative user can populate by some administrative action (i.e. "suspend account", "change permissions", etc.).
My assumptions were that I would produce the same JWT token string value, store that in the database and query the database for that value when the /fetch-access route is called. However, what I realize now is that; at the time that the administrative user is revoking the JWT, I have no way to replicate the same JWT string value at that point in time.
To illustrate my point;
const jwt = require('jsonwebtoken')
let refresh_token_on_login = jwt.sign({user: 'bob'}, 'secret123', {expiresIn: '7d'})
let refresh_token_on_revoke = jwt.sign({user: 'bob'}, 'secret123', {expiresIn: '7d'})
console.log(refresh_token_on_login)
//eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZXN0Ijp0cnVlLCJpYXQiOjE2MDA4Mzg2NzUsImV4cCI6MTYwMTQ0MzQ3NX0.X2zBWVr5t3olb5GsPebHULh-j1-iiuyjJmb98jzlZ2Q
console.log(refresh_token_on_revoke)
//eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0ZXN0Ijp0cnVlLCJpYXQiOjE2MDA4Mzg3MTMsImV4cCI6MTYwMTQ0MUxM30.4LDBJv4qrLLzOieDtyXu8vWqJ1EY75vShpUWiX7jepQgg
In order for the administrator to invalidate refresh token that was issued to the user at a prior time, the revoke key cannot be the actual token string, but some other value that gets saved somewhere in the database at the time of login (i.e. UserModel = { last_issued_refresh: 'xyz'}). That same value needs to be embedded in the refresh token itself to be used in checking the black-listed tokens upon /fetch-access requests.
Are my assumptions correct? Is this the only way to do this, or am I missing some key point in how the refresh token gets revoked (by a user other than the client user - such as admin)
I am using the Easy Auth feature of Azure App Service and I am trying to refresh a token with the Google provider.
I followed the Chris Gillum article and correctly called .auth/login/google with the access_type=offline parameter. Then I called .auth/refreshwhich return me a 200 OK with a new authenticationToken. However, when I check the claims of this ZUMO token by calling .auth/me, I can see that the Google token is in fact not refreshed despite the previous successful response. The exp claims (corresponding to Expiration Time) is the same as the previous token.
I tried several scenario : refresh the token immediately after receiving it, 10 minutes before the expiration time and after the expiration time (when the token is no longer valid) but in every scenario, Easy Auth return me a new ZUMO token but the Google token associated is always the same.
Is it normal for the .auth/refresh endpoint to always return the same token (same exp claims) with the Google provider ?
As Exchange authorization code for refresh and access tokens states about the refresh_token:
A token that you can use to obtain a new access token. Refresh tokens are valid until the user revokes access. Note that refresh tokens are always returned for installed applications.
And the response from Refreshing an access token only contains the access_token,expires_in (The remaining lifetime of the access token in seconds),token_type.
Is it normal for the .auth/refresh endpoint to always return the same token (same exp claims) with the Google provider ?
Using the Log stream under the MONITORING section of your app service, you could find the detailed log when calling .auth/refresh as follows:
Moreover, the exp claim when calling .auth/me represents the expire time for the authenticationToken instead of the refresh_token.
And you could leverage jwt.io to decode your authenticationToken and compare it with the exp user claim.
I have a angular client app and a .net web api server.
I'm trying to understand how to implement security in the best way using tokens.
I thought about few options, and I don't know which one is the best, or if there is a better way.
JWT with expiration
1.User login with credentials -> Server returns a JWT with expiration (for example 60 minutes from login time). Each valid request to the server within this 60 minutes the server returns a new JWT token with a new expiration of 60 minutes. If user didn't send server request for 60 minutes he must login again.
This solution is very similiar to sessions.
Oauth2 - I don't think I understand this protocol correctly, so I apologize if what I'm saying is not correct.
2.User login with credentials -> user gets a refresh_token and access_token.
For every request, the client attaches the access_token. If server returns 401 (unauthorized) the client uses the refresh_token to create a new access_token and re-send the failed request with the new token.
The problem in this flow, for me, is that I don't know if I got unauthorized because the token was invalid or the user tried to access unauthorized resources.
This led me to a third solution.
3.User login with credentials -> user gets a refresh_token, access_token and access_token_expiration. When the user wants to create a request to the server, he checks if access_token has expired. If expired, the client will request a new access_token with new expiration and only then perfroms the request.
And 2 more little question about auth2:
1.Why do I have a refresh_token and access_token? Both of them are stored in client local storage. Why not to always use the refresh_token? For the server it makes sense to have a refresh_token and access_token since the refresh_token is secured.
2.Does the refresh token have an expiration date?
If it does, how can I create a new refresh token?
If it doesn't, isn't it a little unsave to give the ability to stay connected forever?
Thank you very much for your help
Option 3, login with credentials and getting an access token, refresh token and expiration time is the usual way.
eg.:
{
"access_token": "eyJ0eXA....CqVJcc",
"token_type": "bearer",
"expires_in": 3599,
"refresh_token": "AQAAAN...H2JXjIUAQ"
}
the expiration time of the JWT access token can also be found in the token itself in the payload field exp, in form of a UNIX timestamp:
{
...
"exp": 1500547257,
"nbf": 1500543657
...
}
With that information you can implement your own mechanism to check if your access token is still valid and refresh it when necessary.
The refresh token usually also expires. When the refresh token is expired, you need to start again with the credentials.
Additionally you can read this for further information about the topic: https://auth0.com/learn/refresh-tokens/
And here is a tutorial that talks about handling of refresh tokens in Angular:
http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/
I am using the following code, along with my refresh token, to request a new access token:
exports.getTokenFromRefreshToken = function (user, callback) {
request.post({
url:'https://login.microsoftonline.com/12345678-1234-1234-1234-2f189712345/oauth2/token',
form: {
grant_type: 'refresh_token',
refresh_token: refresh_token,
client_id: client_id,
client_secret: client_secret,
resource: 'https://graph.microsoft.com'
}
}, function(err, httpResponse, body) {
if (!err) {
var tokens = JSON.parse(httpResponse.body);
console.log('getTokenFromRefreshToken() tokens = ' + JSON.stringify(tokens));
callback(null, tokens);
}
})
};
The httpResponse includes everything that I get when I make the original token request (from the code), but without a new refresh token. I was under the impression that I would also receive a new refresh token. Is that not the case?
You get a new refresh token only when you are including the offline_access scope.
ref.: https://azure.microsoft.com/en-us/documentation/articles/active-directory-v2-scopes/
The offline_access scope gives your app access to resources on behalf of the user for an extended time. On the work account consent page, this scope appears as the "Access your data anytime" permission. On the personal Microsoft account consent page, it appears as the "Access your info anytime" permission. When a user approves the offline_access scope, your app can receive refresh tokens from the v2.0 token endpoint. Refresh tokens are long-lived. Your app can get new access tokens as older ones expire.
Refresh tokens aren't refreshed the same way you can get a new access token using the refresh token. When a refresh token expires, you will need to need to get the credentials and do the initial token acquisition again.
More info here: Refreshing an Access Token
It looks like it should work except you seem to be missing the redirect URI. I have a working version of this call but it includes this redirect_uri. It produces for me both a new access and refresh token.
--
http://graph.microsoft.io/en-us/docs/authorization/app_authorization
Renew expiring access token using refresh token
The redirect URL that the browser is sent to when authentication is complete. This should match the redirect_uri value used in the first request.
I had the exact same issue, caused a headache for a while until the problem was found.
Seems like you are probably logging in with a Guest MS account (previously known as Live) and thus getting a 12hr expiry refresh token with no rolling window.
You need to use a full MS account to get the refresh token back in the response body (which is a token that will last 14 days), with a rolling window of 90 days.
For as long as you use a Guest MSA you will not get a refresh token back. Your code is correctly structured as far as I can see, and I don't believe you need a redirect_uri header as stated above, they are optional fields according to doco.
For more information on the types of refresh tokens, see this blog post:
Azure tokens