I just Started using Google Drive API using python to download File. I'm seeing it requires authentication for the first time and generates a token.pickle file. From next time onwards we can use this token file for API call.
Note : The file token.pickle stores the user's access and refresh tokens.
What I needed to know is when this token file will expire ? If it expires then how to extend it's validity ?
I've gone through many google documentations but couldn't find anything clear regarding this.
If anyone can suggest me any info on this, that will be most welcomed.
Refresh tokens shouldn't expire but they can.
If the user removes your access though their Google account the refresh token will expire
if the refresh token has not been used in six months it will expire.
When you a user authenticates your application you get an access token and refresh token, if they authenticate your application again, you will get another access token and refresh token. You can have up to fifty refresh tokens for a users account and they will all work but after 50 the first one will expire.
Access tokens expire after an hour and you use the refresh token to request a new one.
Update for 2021
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.
If your app's publishing status is in 'Testing', then the token will last for 2 weeks only.
If its publishing status is 'in Production' then the token has no expiry. However if any sensitive scopes are there and not verified in your app, then the number of users also limited.
These are all tested but seems no official documentation is available yet.
Related
In my python website, I added dropbox refresh token, App key and Secret key. And in settings.py file I generate access token from these details.
Now, my question is that how it will get new auth token after refresh token after expire it . Settings.py loads only one time when build is done and project starts. after expire token, it giving errors.
Apps using the Dropbox API can get long-term access by requesting "offline" access, in which case the app receives a "refresh token" that can be used to automatically retrieve new short-lived access tokens as needed, without further manual user intervention. The refresh tokens themselves do not expire.
The Dropbox SDKs can handle this automatically for you. For the official Dropbox Python SDK, you can find examples of this flow at the following links:
https://github.com/dropbox/dropbox-sdk-python/blob/main/example/oauth/commandline-oauth-scopes.py
https://github.com/dropbox/dropbox-sdk-python/blob/main/example/oauth/commandline-oauth-pkce.py
Otherwise, if you're not using a Dropbox SDK, refer to the following resources for information on how to implement this process in your code:
https://developers.dropbox.com/oauth-guide
https://www.dropbox.com/developers/documentation/http/documentation#authorization
https://dropbox.tech/developers/using-oauth-2-0-with-offline-access
I am trying to build an python application for my server to run 24 hours and overwrite a file in dropbox every minute. When I built this application it stopped working after an hours for new token. I can't awake 24 hour to add new token every token. I just want a way that help me in doing setup of this. With dropbox there is no option to remove short length expire from token. Please keep it simple to underatnd easily dropbox documentation is hard for me to understand.
I just want a solution for this problem. I tried refresh token but it also required user interaction so no use.
Using refresh tokens is the right solution here. Just like with Dropbox access tokens, manual user interaction is required initially to get a Dropbox refresh token, but once the app has a refresh token it can store and re-use it repeatedly without further manual user interaction.
For reference, Dropbox is in the process of switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.
Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention. You can find more information in the OAuth Guide and authorization documentation.
You can find examples of using the OAuth app authorization flow in the Dropbox Python SDK here.
I am developing an app that creates a public Spotify playlist for a user who has given proper authorization to do so.
I am using Flask and Python requests library to accomplish this, but after I've sent a few consecutive POST requests to get an access token from Spotify (using authorization code obtained from previous logic), it begins to fail. I am referring to Step 4 of Authorization Code Flow from this link: https://developer.spotify.com/web-api/authorization-guide/#authorization_code_flow
I know the authorization code is valid, because it doesn't fail for the first few times I run the request (maybe 5-10 times).
When I print the response from the POST I get the following:
{'error_description': 'Authorization code expired', 'error': 'invalid_grant'}
I assume I am not using the authorization code fast enough to get an access token (after repeatedly failing on code logic before the access token POST request, I guess?) but how am I supposed to reset and refresh the authorization code so I can keep making requests repeatedly? Any info on how long I am disabled and generally good programming practice to avoid this scenario?
When you use the authorization code to get your access token, you will also get a refresh token back in the same message. Use that refresh token to request new access tokens, when the access tokens expire.
How to use the refresh token is written on the same page you linked to, just a bit further down: https://developer.spotify.com/web-api/authorization-guide/#request-access-token-from-refresh-token
I agree that this is not the easiest to understand, but there are good reasons for all these things. It is also a standard called OAuth2, which many websites use to let users authorize apps to access their data, so it is useful in a lot of places.
In this specific case: "why do I need a refresh token to get an access token, I already have an authorization code to get an access token?", it is because the authorization code has leaked to the outside because it was returned to you via the user's browser.
An authorization code is obtained when the user grants permission for the third-party application (the Client). As per OAuth's 2.0 specification the authorization code must be used once and it's recommended that it have a maximum lifetime of 10 minutes to mitigate security flaws.
Read more about authorization code here:
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2
On the other hand, instead of boring the user to go through all the OAuth 2.0 dance again (to authenticate and to grant permissions), the server side of Client application can use Refresh Tokens to ask for a new token when it's expired.
More about refresh tokens can be found at section 10.4 of OAuth 2.0 spec.
https://www.rfc-editor.org/rfc/rfc6749#section-10.4
I'm using google-api-python-client library to work with Google Content Api for shopping.
I'm trying to build script, that would every 24 hours pull data from Content API for Shopping and update some tables on own server.
But I faced up with auth problem.
I moved through steps in guide, created client id, and even recieved refresh token via --noauth_local_webserver option.
But this token became invalid in few hours and require client to interact with app again.
I have same script, but for Google Adwords Api. In that case my refresh_token lives much longer, as for now - few months.
Can you please point me, where I'm doing something wrong. Thanks.
You need to implement OAuth Service Account authorization.
This is server-to-server authorization, so no human interaction is needed after Refresh Token has expired.
Does this quick-start code handle refresh tokens? If so, where/how?
https://developers.google.com/gmail/api/quickstart/quickstart-python
I am working on a Python application that needs to have continuous/unfettered access to Gmail account emails, so I want to make sure that I am handling the scenario described on this page:
https://developers.google.com/gmail/api/auth/web-server#send_authorized_requests_and_check_for_revoked_credentials
Specifically, the "If your application requires offline access, the first time your app exchanges the authorization code, it also receives a refresh token that it uses to receive a new access token after a previous token has expired. Your application stores this refresh token (generally in a database on your server) for later use" paragraph.
It's not clear to me if/how this is handled by the quick-start code. Thanks!
I figured this out. The refresh token, if saved for offline access by the application, is used to perpetually request new access tokens (as they are short lived/expire). This quick-start code does save the refresh token in the stored credentials (the STORAGE file) and wraps the Oauth 2.0 methods that get new access tokens from the authorization server when needed.
If for some reason you need to get another refresh token, you can request one from the authorization server, after making the user to approve your application again:
From https://developers.google.com/gmail/api/auth/web-server
"Always store user refresh tokens. If your application needs a new refresh token it must sent a request with the approval_prompt query parameter set to force. This will cause the user to see a dialog to grant permission to your application again."
More info about authorization server requests:
https://developers.google.com/accounts/docs/OAuth2WebServer
Just to add,Limits apply to the number of refresh tokens that are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens to go over one of the limits, older refresh tokens stop working.