This question already has answers here:
How to fix Google API 'invalid_grant' error
(2 answers)
Closed 12 months ago.
I read here that 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. Does this mean that despite calling the refresh function from within Python, one must manually relogin every 7 days? Am I interpreting this correctly? Or is it possible to automate this such that a new Refresh token is issued for 7 more days all within the code?
I am making this project just for myself, so I see no reason to publish it (I want to keep it in testing), but I need the credentials to never expire (so that my intervention is never required after I generate the first token). Any help is appreciated!
Yes you understand well, so the token expires after 7 days, but pay attention, only in "testing" mode. This mean that you could switch your app in "production" mode and the token won't expired.
But take a look also to another detail, even if in production you will 50 token per your Client user (client-user). Not client_id. This is mean that, for every person that log in your application you can have all of them authenticated max 50 times. Each Refresh token you receive will work. After the 50th the oldest one will stop working. On the other hand the token will works for up to 6 months I think, if it hasn't been used for 6 months it will be invalidated.
So there isn't a way to have a lifetime token, and, for security reason, is a correct approach, by the way Google itself provide an antipattetn that you can use to set a long life token, for info read google long expiration token
Related
For the past few years I have been using an unattended remote server to process invoices through the XERO API (Oauth 1.0)
Periodically (every financial year) we create a new XERO organisation to keep things tidy and avoid slow down.
I have just come to create a new organisation and associated app but have found that I can only use Oauth 2.0, which I do not have a massive issue with, BUT the fact I have to 'user' authenticate is going to be a real problem as my process is 'unattended' and started via CRON jobs.
Can anyone tell me if there is a way around this? and if not are there any solutions to do this?
Alternatively is there any way I can change one of my existing Oauth 1.0 apps to point to a different organisation (i.e. the new one I have just created)?
It seems a little short sighted not to have considered unattended processes, I cannot be the only person doing this??
Any help or pointers would be greatly appreciated.
Thanks,
Mike.
Yes you are not the only one doing this :) & yes, private apps are essentially deprecated end of 2020 - the move was not taken lightly. Since every API action through Xero's api is on behalf of a user account the team decided to move towards OAuth2.0 (Industry Standard) with a user consent screen.
If you need these long standing api connections on behalf of a user - they will need to initially authenticate that API connection at least a single time to get you an access_token and `refresh_tokenà . Access tokens are valid for 30 minutes, while the refresh token is good for 60 days.. So as long as you refresh > 2 months you can persist that longtail process.
If you don't have the means to build out that initial authentication screen to have your user validate on their own, you can use this CLI tool to get your initial token set to securely store in your remote server. An additional change is that that (or some) process will need to ensure the token is refreshed before use, and has given permissions to connect to a specific user's tenant-id as they might be a part of multiple Xero orgs & that manual consent screen is where a user selects which tenant/org they are giving API permissions to.
CLI to get Xero tokens from the command line
https://github.com/XeroAPI/xoauth
More info here: https://community.xero.com/developer/discussion/109207632#answer110970761
UPDATE
client_credentials aka machine to machine are coming to Xero's OAuth2.0 gateway.
You can read more about it here:
https://developer.xero.com/announcements/custom-integrations-are-coming/
In OnLogin, Access token is valid for 10 hours and Refresh token is valid for 45 days.
I want to generate a new tokens(Refresh +Access Token) after 9.59hours.
My Question:
What will happen to the refresh token.Will it ever expire as I am generating the tokens(Refresh + Access token) for every 10 hours?
What is the best approach? Should I be refreshing the token or generating a new token for every 10 hours.
What can be done if the rate limit of 5000 is crossed with in an hour. Please suggest any alternatives.
Any suggestions or comments
Nope. Refresh token lifespan is measured from when it gets created. If you create a new one via refresh it'll 'live' for 45 days. The allows you to hold on to the tokens and still be able to make a new access (and refresh) token even if you haven't used them for a long while.
Some folks choose to simply use the generate token call and use the clientID/Secret to constantly generate a new access token. But this is not as secure as using the access token to make calls until you get a response that it's expired, and then use the refresh token (and refresh token call) to get a new access / refresh pair. The minimizes the chances that your secret/clientID will ever get leaked.
Once you've exceeded 5000 / hour you're done for the hour. I'm curious what scenario you have that needs more calls than this.
This number can be raised for certain extraordinary circumstances (You're a giant customer with a big account) but that's between you and your customer service contact.
Question 1
We are currently using ADFS and OAuth (using Windows Server 2012 R2 with ADFS 3.0). Our test applications (both WPF and mobile apps) can successfully authenticate and get an Access Token and a Refresh Token. We can after that continue to use the Access Token until it expires and after that use the Refresh Token to get a new Access Token.
So far so good, but the problem is when the Refresh Token expires, we need to force the user to enter their credentials again. Our aim is to have the user to only enter their credentials once and then use a short lifetime for Access Token and a Persistent lifetime (or really really long) for Refresh Tokens.
According to some blog posts when using a Refresh Token you should get a new Access Token and sometimes also a new Refresh Token, but in our case we never get a new refresh token, so that one eventually expires.
Is this even possible using ADFS 3.0 and OAuth to have a persistent Refresh Token? or get new refresh tokens from time to time so that the user doesn't have to enter their credentials again? or is it possible to have a really long lifetime for refresh tokens.
Question 2
There is also a lot of different properties you can set in ADFS that we are not sure of
TokenLifetime - This is the access token lifetime? what is maximum value?
SsoTokenLifetime - This is the refresh token lifetime? what is maximum value?
PersistentSsoLifetimeMins - what is this?
PersistentSsoEnabled - I guess should be set to true to have refresh tokens working
This post describes a semi-official answer. Here's an example of setting the required values -
Set-AdfsRelyingPartyTrust -TargetName "RPT Name" -IssueOAuthRefreshTokensTo AllDevices
Set-AdfsRelyingPartyTrust -TargetName "RPT Name" -TokenLifetime 10
Set-AdfsProperties -SSOLifetime 480
For the specified RPT, this would issue access tokens with a lifetime of 10 minutes and refresh tokens to all clients with a lifetime of 8 hours.
The only semi-official guidance I have been able to dig up is this slideset:
http://www.oxfordcomputergroup.com/wp-content/uploads/Access-the-future-Alex-Simons.pdf
which states:
Configurable Refresh token support
Lifetime:
workplace joined device 7 days (PSSO lifetime)
Non-workplace joined device max. 24 hours.
Persistent refresh token support in ADFS sure would be nice, but it seems they see the feature mostly as a tie-in to their mobile device management offerings.
I'm reading/learning about token based authentication and I'm understanding it to a degree but the following questions have arisen.
If you log into site A you are given a token, this token will expire 24 hours after creating it.
You also visit Site B which calls an API from site A that allows you to give site B access to your information stored on site A. At this point a token is passed to site B to use for 24 hours.
Is this the same token? (So if you logged into Site A via site B, 23hrs59mins after logging into site A directly you would only have a minutes access to your info through site B before needing a new token?)
If its not the same token and you store your token in a table which links it to the user would you have multiple tokens per user?
Is it wise to to generate your token(s) as a random uniquely generated code and store it in the database along with the users log in details or is it better to create a token which takes a combination of the log in details and encrypts it (if so, how do you change the token each time).
Is this the same token?
Well that depends on Site A. Using the same token would mean that Site B has access to everything that your login on Site A allows you to access. If this didn't seem appropriate, then Site A would generate a new token with a more limited access. In this case, there would be multiple tokens per user.
So if you logged into Site A via site B, 23hrs59mins after logging into site A directly you would only have a minutes access to your info through site B before needing a new token?
If it expires 24 hours after creation (which you mentioned), then yes. Often the expiry would be updated upon every access though, so this might renew it for another 24 hours.
Personally, I would (and have) generate token as a random uniquely generated code. I think either would work though, and I'm sure you can find lots of opinions out there, like
here or here.
I am using server-side flow for authenticating users in my App. Most of the users are getting a 60-day valid token. However, recently there are few users whose tokens are valid only for 24 hours (Not 1 or 2hours which is the case with short-lived tokens).
Due to this problem users are stopping usage of the App as they have to authenticate every day in order to continue using it.
Any help would be much appreciated.
Thanks