When I obtain an access_token from the Google API, it comes with an expires_in value. According to the documentation, this value indicates "The remaining lifetime of the access token".
What are the units of this value?
The spec says seconds:
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22#section-4.2.2
expires_in
OPTIONAL. The lifetime in seconds of the access token. For
example, the value "3600" denotes that the access token will
expire in one hour from the time the response was generated.
I agree with OP that it's careless for Google to not document this.
Have a look at: https://developers.google.com/accounts/docs/OAuth2UserAgent#handlingtheresponse
It says:
Other parameters included in the response include expires_in and
token_type. These parameters describe the lifetime of the token in
seconds...
Since there is no accepted answer I will try to answer this one:
[s] - seconds
From Google OAuth2.0 for Client documentation,
expires_in -- The number of seconds left before the token becomes invalid.
Related
I need to generate the expiration time for refresh token, refresh token should expires in 200 days, how to generate exp time for this? Is there any libraries? And what format should be? unix, maybe YYYY/MM/DD etc? Any options please, thank you!
You could use json web tokens and make use of the jsonwebtoken package.
https://www.npmjs.com/package/jsonwebtoken
Specifically, if you make use of the options.expiresIn value this will take care of the date calculations and logic for you. When using the verify() method it will fail if the token has expired.
I'm using the python requests-oauthlib package to connect to the Microsoft Graph. I am using the OAuth 2.0 Client Credentials flow.
The following simplified code works perfectly fine:
from oauthlib.oauth2 import BackendApplicationClient
from requests_oauthlib import OAuth2Session
client = BackendApplicationClient(client_id='myclientid')
token_url = "https://login.microsoftonline.com/mydomain.onmicrosoft.com/oauth2/v2.0/token"
msgraph = OAuth2Session(client=client)
msgraph.fetch_token(
token_url = token_url,
client_secret = 'myclientsecret',
scope='https://graph.microsoft.com/.default')
response = msgraph.get(
url="https://graph.microsoft.com/v1.0/users/user#mydomain.com/messages")
While this works, the Bearer access token in this case is only valid for 1 hour. The requests-oauthlib package has support for refreshing tokens but it seems limited to token types that come with separate refresh tokens. The client credentials flow as used with the Microsoft Graph only issues an access_token.
So my questions are:
Is there a way to make the requests-oauthlib refresh the token automatically in this use case or do I need to manually track the age of my token and explicitly refresh it as needed?
I'm not wedded to requests-oauthlib so if there is a better library that accomplishes the auto-refreshing I'd be interested in using it.
This behavior is by design (and aligns with the OAuth spec). The only OAuth grants that support Refresh Tokens are Authorization Code and Resource Owner Password Credentials. The Implicit and Client Credentials grants only return an Access Token.
More importantly, since the Client Credentials flow isn't interactive, there is no need for Refresh Tokens. You simply request a new token when the old one expires.
As far as I can tell, there is still no built-in way to do this automatically using requests-oauthlib. There is a ticket about it on their GitHub with a couple of different ideas on how to do it, but nothing out of the box: https://github.com/requests/requests-oauthlib/issues/260
I know this is an old question, but it seems unanswered, so please allow me to give it a try.
My initial answer was:
I dare make the hypothesis, reading your mention of lack of refresh token, that you did not add offline_access in your requested scope - if you want it to be part of the answer from the Microsoft authentication service, you have to (please refer to https://learn.microsoft.com/en-us/graph/auth-v2-user#token-response and the various pages around for more details).
which was indeed totally irrelevant for the scenario used, as commented by Mark, and also clearly stated in https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/resilience-daemon-app#cache-and-store-tokens:
It is important that applications use the "expires_in" property to determine the lifespan of the token.
So as an answer to your question 2., the above link also suggests the use of MSAL (MS Authentication Library):
MSAL implements and follows [best practices for caching and storing tokens] automatically.
what the why use MSAL wiki page seems to confirm:
It also adds value by [...] maintaining a token cache and refreshes tokens for you when they are close to expire. You don't need to handle expiration on your own.
For your question 1., I indeed did not find a standard way in requests-oauthlib to do so, either.
In this kind of situation, I usually don't monitor the age of the token, but just catch the 401 return code and fetch a new token.
To do so, I found suitable to tweak the first example of the Requests-OAuthlib - OAuth 2 Workflow - refreshing tokens section, replacing their call to refresh_token(refresh_url, **extra) by a new call to fetch_token().
What I usually use in order to avoid repeating the try...except... code piece, is to put it in a wrapper decorator (got a good inspiration in https://realpython.com/primer-on-python-decorators/#a-few-real-world-examples ) around my API-calling functions / methods.
Hope this time it helps more...
Where does a JSON web token live? After doing jwt.sign and adding the payload / expiring date, what happens next, where is it stored ? I cant seem to find anything about it.
Thanks in advance.
JWT is not stored anywhere, its very existence contains everything. Its consisted of three parts, first one is hashing method, second one contains all the information you put there and the last one is signature so you can check if the token is valid or not (if you have secret).
This is actually the main reason JWT is so popular and used - as it can carry information through the multiple systems that can be verified by authorized systems.
I recently registered to Microsoft Azure and set up a Cognitive Services Account. Using the instructions from the Text Translation API Documentation I was able to retrieve an authentication token from the /issueToken service using the interactive online example. However, if I want to use that token (for example for the interactive /translate example) I end up with the response
<html><body><h1>Argument Exception</h1><p>Method: Translate()</p><p>Parameter: </p><p>Message: The received token is of incorrect token type.</p><code></code><p>message id=0344.V2_Rest.Translate.3D8A6FF1</p></body></html>
What am I doing wrong? What should the token look like and in what format should I supply it? In the online example I specified the token by setting the appid field to "Bearer [token]" where [token] is the response from /issueToken.
In my case the token is a 687 characters long string which can be separated into three parts (using '.' as delimiter). The first two parts are base64-encoded and just contain some JSON-encoded information that stays constant (except the expiration date field). The third and last part changes everytime and can not be decoded using base64. Instead of supplying the full token I also tried to just use various substrings of the full token but without any success so far.
I also tried authenticating via curl using the Authentication-header instead of the appid-field, which also did not work for me.
The token actually has to look like it is described in the question text (at least as of now). The problem in my case was that I used the wrong subscription key. Note here: You get a different key for the translation API and the speech API each; even though both run under Cognitive Services and even if you connect both through the same resources.
I post this as an answer to my question because I want to confirm that all the steps listed above are correct and because I hope that it may help people who do the same mistake as I did.
I've referred to this question Instagram API: The access_token provided is invalid, before posting this question myself.
My situation is quite similar, where I've just registered a new app yesterday, and it is now in Sandbox mode. I do understand that my access to instagram data is quite limited. However I've got no idea why even the simplest of request as below, I received error The access_token provided is invalid.
https://api.instagram.com/v1/users/self/?access_token=ACCESS-TOKEN
I'm quite certain that I'm doing this right, however just in case I'm doing it wrong. First I will need to login to my app with the below URL, where I would need to change to my own CLIENT-ID and REDIRECT-URI.
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
Upon successful login, it will redirect to my REDIRECT-URI example: http://your-redirect-uri?code=CODE
I copy the generated CODE and append with https://api.instagram.com/v1/users/self/?access_token=CODE, which it is returning me with The access_token provided is invalid.
Please correct me if I'm doing it wrong.
For those who faced the same issue as me, I realised that I needed to change code to access-token. Because I'm using Implicit flow, I needed to change that parameter to return me a token.
From:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
To: https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token