So I have an action that has account linking configured using auth code flow. The refresh tokens are valid for a few years and do expire. As there are existing people linked to the actions I would like to avoid having them relink to get a new refresh token.
The IDp supports a refresh token rotation. If I were to implement this would this be supported by the actions on google platform? Would the new refresh token be stored?
https://auth0.com/docs/tokens/concepts/refresh-token-rotation
As FYI having an a refresh token which without expiry is not an option in this case due to security policy requirements.
By docs yes:
Note: You can optionally return a new refresh_token in your response. For more information about when returning a new refresh_token is preferred, see Working with tokens.
See: enter link description here
There is no mechanism to rotate a refresh token. If a refresh token expires and a new access token cannot be retrieved, the user will need to reauthenticate their account. You can read the entirety of the OAuth guide for more specifics.
Related
The docs for account linking for actions on google say you must provide a refresh token for implicit flow - it doesn't mention if this is required for Authorization code flows. https://developers.google.com/actions/identity/oauth2-implicit-flow
So if I had an end point that produces access tokens but doesn't issue refresh tokens (the access tokens do expire but I require a user to authenticate again in this instance - this is a security requirement outside of my control) can we still use the Authorization Code flow in this instance?
Finally how would this work with 3rd party login providers? So if I offer Facebook Login on my web app then I also won't receive a refresh token. I know I can get an extended Facebook token, but again there's no guarantee a user will use my action whilst that token is valid.
In both cases do we just return a 401 unauthorized error and will this prompt the user to sign in again from a google action side?
Take a look at the Google Assistant Smart Home sample, which uses Authorization codes. When the HomeGraph makes an HTTP request to your cloud, it does so for a particular user. It tries to include a token, but if the token expired, it sends a new request to get the latest access token.
I'm using the .net api for v2 using the code flow scenario. I was under the impression that this is what you use to get a refresh token you can save and re-use to get new access tokens after the user authorizes your app once.
after a doing a call like below, I navigate the uri the call provides.
var redirect = DropboxOAuth2Helper.GetAuthorizeUri(OauthResponseType.Code, AppKey, RedirectUri, user.ConnectState);
I parse the result for the code parameter which I then feed to ProcessCodeFlowAsync(). That only works to get the access token once. If I save and try to use it again, I get "code has already been used : invalid grant" errors.
I thought what I was getting was a refresh token but repeatedly feeding it ProcessCodeFlowAsync is not working. How do I get a refresh token that I can use repeatedly to get access tokens without having to have the user authorize every time. I am cacheing and re-using the auth token not the access token by the way.
The Dropbox API doesn't use refresh tokens. Instead, you should just store and re-use the access token you get at the end of the app authorization flow.
The user or app can revoke an access token at any time though, so if/when API calls start failing due to a revoked access token, you can prompt the user to re-link the app if they want to continue using the integration, so the app can get a new token.
(The "code" you pass to ProcessCodeFlowAsync is an "authorization code", which is not re-usable.)
The accepted answer was probably correct at the time but Dropbox API now does support refresh tokens.
Check the Refresh token section here:
https://www.dropbox.com/lp/developers/reference/oauth-guide
I'm using OAuth as:
a secondary method to sign users into my web application (rather than manually providing their name, email and password)
a way to receive to receive user data throughout the website.
What would be considered best practice when storing access tokens? I have two options:
Store access tokens in cookies
Store access tokens in a database
What are the advantages and disadvantages of either choice?
Regarding token expirations, what should be done to handle this?
One way I know I could handle this is by checking whether there was an error when calling the API and so requesting a new token and then calling the API again. However when requesting a new token, will I require the user to sign back in again? I would imagine this would be a problem when a page on my website requires data from Facebook, but to retrieve it, users have to log back in.
I don't understand how other websites manage to maintain access to Facebook, Google or Twitter APIs without requiring me to log back in again, especially when I'm on another device where I haven't once logged in to Facebook, Twitter or Google. How do they do this? Thanks.
If authentication is done using Google OAuth2.0. Google provides two tokens namely, Access Token and Refresh Token.
Access tokens have limited lifetime for 3600 seconds , but refresh tokens are valid for longer period of time.
Refresh token also expire. Read "Token expiration" section of the Google OAuth2.0 link
One can obtain new access token from refresh token without re-login. ReST api
So, one can have logic implemented to check for time elapsed after access token was generated and take precautionary steps for new access token generation.
Google tokens expire in 3600 seconds, so one can get access token say after every 3500 seconds and update the older access token stored with new one for further use. Also one other way could be, to set refresh token in GoogleCredential which is passed as parameter(httpRequestInitializer) while creating the service of any api.(For example look for Drive.Builder)
If you are not storing refresh token from which access token can be regenerated, you have to authenticate again to get new token.
what is the expiry time of github oauth access token. And also how do I renew it. I don't see any refresh token in their documentation. Please guide me. Thanks in advance.
2014: As commented in this "GitHub OAuth Busy Developer's Guide"
Tokens don't have to expire.
They only send back the access token and an expiration (field "expires_in", seen as far back as 2013) if the offline_access scope is not requested (as it is the case for a refresh token).
Right now, GitHub just assumes all apps want offline access.
You can check an OAuth application authorization, delete it or revoke it.
But the token itself doesn't seem to be bound to an expiry date unless they are not use for one year.
badsyntax adds in the comments:
I also found this useful:
"An OAuth token does not expire until the person who authorized the OAuth App revokes the token."
From "Migrating OAuth Apps to GitHub Apps".
Stokito points out in the comments to rfc6749 / 4.2.2 Access Token Response:
expires_in
RECOMMENDED.
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.
If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.
Generally, the access_token of GitHub has no expiry until you revoke the OAuth token.
You can consider to opt in to GitHub App expiration token beta feature. This would make your app use expiring user tokens valid for 8hrs, and refresh tokens valid for 6 months
Here's an official step by step guide
GitHub will automatically revoke an OAuth token or personal access token when the token hasn't been used in one year.
https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/token-expiration-and-revocation#token-expired-due-to-lack-of-use
Interestingly, some other OAuth providers issue short-lived access tokens and long-lived refresh tokens, as suggested discretionally in the OAuth spec. For example, GitLab OAuth "access tokens expire in two hours" and each refresh token may only be used once. This mitigates the damage that stolen access tokens can do.
This is the access token associated with my Facebook application -- the thing that comes back from https://graph.facebook.com/oauth/access_token?grant_type=client_credentials&client_id=APP_ID&client_secret=APP_SECRET. Can I get this once from FB and save it away somewhere for future use, or do I need to refresh it on a regular basis?
Access Token Tool - Facebook Developers
App tokens do not expire and should be kept secret as they are related to your app secret.
I don't know for sure, but since the documentation does not state that you get back an expiration time for the access token, I guess that it's an educated guess that it does not expire.
But why does it matter? the application authentication process is much simpler than the one with users, so just save the token somewhere (db, memory) and then try an api call, if it fails just issue one call to obtain a new token, save that, and continue as usual.
If you want a token to manage a page, never-expiring token can be obtained by
Get user token
Exchange user token to long-living token (Valid for 30days)
Obtain a page token with this user token (This page token is not going to expire)
When you check the token you've got, check it on Debugger. You will now see 'Expires Never'.
Documentation is on Facebook Developers ,Scenario 5: Page Access Tokens
My app access token does not seem to have changed for just under a month. I do not know if it changes. For fun I just changed my app secret...
My app access token then immediately changed and when I try to use the old one I get a
HTTP 400 error with a message body...
{"error":{"message":"Invalid OAuth access token signature.","type":"OAuthException","code":190}}
My advice is save the access token and use it. Unless you get the message above in which case obtain a new one and use that. One thing that I have not checked yet is if you get the same result if the user access token (that you may be querying) has expired instead.
For each and every user token (which is what you're getting from your link), there is an expiration date. Take one of those tokens to https://developers.facebook.com/tools/debug and debug it. You will see that generally they expire within 60 minutes or so.
To extend that user token, call the exchange command (https://developers.facebook.com/docs/offline-access-deprecation/) to get it to become a 60 day token. That user token has to be still valid (not expired) to do this.