We are using the Google Calendar API. When attempting to revoke the access token (we've also tried the refresh token just in case) for the account, we get the following 400 response:
b'{\n "error": "invalid_token",\n "error_description": "Token expired or revoked"\n}'
We also tried the following endpoints:
accounts.google.com/o/oauth2/revoke
oauth2.googleapis.com/revoke
We want to invalidate the token and remove ourselves from the user's "Third-party apps with account access" list. However, it should be noted that the tokens are perfectly valid, so the response from Google is confusing. We have scoured the documentation and every forum we could find and still could not solve this issue.
revoke access is preformed using an access token and not a refresh token. Use the refresh token to request a new access token. Then use that to revoke the users consent.
Related
I am trying to use GA4 API (with Google Python Client & Google Analytics Data Python Client) of Google with the Credentials authentication:
credentials = Credentials(
token=config['access_token'],
refresh_token=config['refresh_token'],
client_id=config['client_id'],
client_secret=config['client_secret'],
token_uri="https://accounts.google.com/o/oauth2/token",
scopes=['https://www.googleapis.com/auth/analytics.readonly']
)
This is working when my access token is not expired. However, this access token is expiring after 1 hour and I want to refresh it via following method:
credentials.refresh(google.auth.transport.requests.Request())
However, this code is returning "invalid_grant" error.
For that problem, I checked almost everything suggested (i.e. system clock/ntp, user permissions, etc.) however I couldn't fix the problem.
Also, I can't figure out about the refresh_token that I use is valid for Google Analytics 4 or not.
So, the questions are:
How can I able to solve this problem?
How can I assure that the refresh_token is valid for GA4?
If not valid, how can I refresh the refresh_token?
Is there any suggestion on the refresh of access_token, any other method or anything else?
Thanks
In my case, the solution was creating new OAuth client and generate a refresh_token for that account depend on the Google Analytics scope.
For that purpose, after I create the new client, I downloaded the client_secrets.json and run the Complete Example by Google and finally I am able to refresh the token.
We are using linkedin-ads API in our integration in which the OAuth token is being used to authenticate API requests. But while doing testing, we observed that the refresh token do not work after some time. In the status, it shows like `token is revoked. But, none of us have revoked any tokens. It seems like Linkedin had revoked Oauth tokens because in the document it is mentioned that Linkedin reserves the right to revoke it. So, we just wanted to know that is there any specific reason or activity which can lead to revoking the OAuth token.
Any help would be appreciated.
I'm using directus to grant users access to ressources required by an SPA written in Angular. To authenticate users I created an auth service and interceptor to handle sessions and attach the "Authorization" header. Those services work fine and login as intended. But here comes the problem:
Directus session times are configured with default values (15 min validity for access_token, 7d for refresh_token) but as soon as the access_token expires I cannot retrieve a new one using the refresh token. This bugs me, because the goal is to keep users logged in for the next 7d (refresh_token lifespan) or until logout if they check this option.
My attempts at achieving this:
Since i'm using graphQL, i tried the "auth_refresh" mutation from the authentication documentation. While the access token is still valid, refreshing works fine. After the access token expired there is no way to retrieve a new one via a valid refresh token.
Alternatively I tried to achieve a refresh via the POST request specified by the docs (to double check if it was some sort of config error with graphql) but I encounter exactly the same problems as with graphQL. Directus returns either "401 unauthorized : Token expired."
if i extend the lifespan of the access token for longer than the server defined lifetime,
Response: Sending a token with prolonged life
or "401 unauthorized : Invalid user credentials." if I request a new token without an
"Authorization" header.
Response: Sending no access token
The refresh token is correctly loaded and sent to the server as specified in the docs in both
cases.
Now my questions are:
Am I missing something? I haven't found any further specification in the docs and the Auth0 protocol specifies that a new access token should be retrievable with a valid refresh token.
If this feature is not intended: How could I achieve a "keep me signed in" option with directus? I would like to keep user rights management in one place and do not really want to handle user auth redundantly for my current use case.
2b. Why is the lifespan of the refresh token so much longer than the lifespan of the access token if this isn't intended?
One of my thoughts is, that it has to do with access rights of the "public" role on the "directus_sessions" table. But I can't think of a way to grant only read rights for owned/received tokens, since there are no payload variables available inside the filters. Could this be the cause? Would there be a way to achieve this?
Thx&Greetz
My user has granted all permissions for authentication scopes to google calendar, but the API is returning a 403 error. However, this only happens for some users. Most user do not have any problem.
I reviewed this live with the user as they granted access and can confirm that they did grant access to all the scopes but the issue still persists.
When you are accessing an api endpoint that requests privet user data you must be authorized to access that data. You haven't posted your code or stated which method you are trying to use but as an example lets look at
Events.list in order to use this method the documentation tells us that you need to authorize the user with one of the following scopes
If you authorize your application with a difference scope and not one of these you will get the error message you are seeing Insufficient authentication scopes.
The key to fixing this will be to fix your code to ensure that you are sending the proper scopes, then to revoke the users access and force the system to prompt the user for consent again. The user must see the consent screen again showing the new scope required. Once the user has authorized with the new scope it will work.
It is probably running on an old access token and refresh token without prompting the user for authorize again.
The insufficient scopes means that the user has authorized your application bu
I'm using OAuth 2.0 to log in users in my website. Just like any kind of website, e.g. Google, Asana, etc. .
What I would like to know is if there is a way to revoke ONLY the access token and not the refresh token when the user logs out.
This is what I do:
when a user logs in, I create a session and obtain the access token (and the refresh token if the user logs in for the first time). When the user logs out, I just invalidate the session but the access token is still valid.
Sure, the access token will invalidate after a while or when the user logs in the web app again but what I want to know is if the access token can be invalidated during the log out process.
There's no generic answer to this question as the implementation of token revocation behavior wrt. related tokens is Authorization Server specific. Google will invalidate the refresh token together with the access token that is being revoked, other implementations may choose not to do so. Yet other implementations may not even offer a way to revoke access tokens at all.
For Google you can revoke the access token upon logout as described in https://developers.google.com/accounts/docs/OAuth2WebServer#tokenrevoke but it will also revoke the associated refresh token. You must then go through the authorization code flow again to get a new refresh token, which you could try with prompt=none to avoid the user being prompted.