I have an issue to configuring Redhat Single SigOn (RHSSO) or Keycloak token expiration in seconds, about 30 seconds.
I just found the configuration in minutes. There is a way to adjust it to seconds?
From the Keycloak Admin Console it is not possible; Keycloak allows to specify the access token expiration time in Minutes, Hours or Days, but not in seconds:
Albeit, when one requests a token, the expiration time is display in seconds, namely:
{"access_token":"...","expires_in":60,"...}
The least amount of time that you can set via Admin Console is 1 minute. To be honest, I fail to see what would be the great benefit of having 30 seconds instead of 1 minute.
In the Admin Console, if one tries to specify 0.1 (or 0,1) minutes an error is displayed
Now that being said, it seems that you can use the Rest Full API to get around that restriction. First, request a token on behalf of the admin, extract its access token (let us called $ACCESS_TOKEN). And then call the following endpoint:
PUT <KEYCLOAK_HOST>/auth/admin/realms/<REALM_NAME>
with the following data
'{"accessTokenLifespan":30}'
Now if you request a token for a client on the Realm REALM_NAME you will get the following:
{"access_token":"...","expires_in":30,"...}
30 seconds as expiration time for the access token.
Now, I have not tested this, so it is up to you to find out if everything still works as it should.
Related
The url is signed for 6 hours. The X-Amz-Date and X-Amz-Expires add upto the correct time. However, the url itself starts giving Access Denied errors several minutes before expiry time.
We're using aws-sdk-s3 for ruby, fwiw, in a kubernetes environment.
The problem was the our pods were using InstanceProfileCredentials. These are temporary, rotated credentials, which are also used to sign the urls we generate. So, if the current credential token is expiring in 4 hours, then the url will also be live for max 4 hours, even if we set a higher expiration time for url.
A bit of code to get the expiration of current token:
resource = Aws::S3::Resource.new(
region: 'us-east-1'
)
expiration = resource.client.config.credentials.expiration
# "2021-05-03T11:49:47.569+00:00"
This returns an instance of Time class. Based on this, we were able to calculate the max expiry we can set for a url and avoid 4xx errors.
Refresh Token for Quickbooks expiring after 2 day
Refresh Token for Quickbooks expiring after 1 day
Yes, every 24 hours the refresh token gets changed.
Reference - https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#step-5-exchange-authorization-code-for-refresh-and-access-tokens#understand-token-expiration
As per the doc -
Even though the refresh token is valid for 100 days, the value of
refresh token can change every 24-26 hour period. Hence, you might
encounter a situation where the request token that you received first
is different than the latest one. As a best practice, always store the
latest refresh token received from the API response and use that to
make subsequent calls to obtain a new pair of tokens.
I have session timeout setting as 1 hours, and my initial access_token seems timeout around this time. This is excepted.
And after it timeout, i did token refresh and get a new access_token, then i observed this refreshed access_token seems not timeout in 1 hours, even 5~6 hours after, it still not expired.
So is there refresed access_token never expire? Can someone explain more about this?
Refresh token policy is managed from admin side usually and is different from the initial access token. From what you say the setting you have right now for Refresh token is probably 'Refresh token is valid until revoked'.
When you go to your Salesforce org go to Setup -> Manage Connected Apps - find the connection you are looking for and see what policy you have set. You can set it to expire in number of days, based on usage or Immediately.
I have one quick question related to "acquiring a new access token upon expiration". I have read some tutorials where people write code to manually request a new access token.
In my case I wrote an ASP.NET MVC app to access Google APIs, such as Gmail API, and I am using API Client Library for .NET for that.
After OAuth 2.0 authorization I get back the result object of type AuthorizationCodeWebApp.AuthResult.
Where result.Credential.Token contains AccessToken and RefreshToken properties.
I save the refresh token in my web.config the very first time when it comes back (after the consent screen). All next requests dont have a refresh token, only an access token that expires after 1 hour.
So, my question is - before I make a call to instantiate a Gmail Service, I assign previously saved refresh token:
result.Credential.Token.RefreshToken = WebConfigurationManager.AppSettings["RefreshToken"];
var service = new GmailService(
new BaseClientService.Initializer { HttpClientInitializer = credential });
When result.Credential.Token.AccessToken expires, does Gmail API (or any other API Client Library for .NET) acquires a new access token automatically if result.Credential.Token.RefreshToken was assigned a valid refresh token value previously saved, like in my code sample?
Thank you!
UPDATE - More clarification to my question With the same refresh token, how many times I can aquire a new access token when making calls to Google API?
I will explain: access token expires in 1 hour, right.
If I keep making calls with, lets say, 10 minutes intervals to Gmail API (for example), after 6 calls (1 hour limit), Gmail API will use my refresh token to acquire a new access token. After 6 more calls (1 more hour) the whole thing repeats itself. Question - is there a limit to it? Remember, I am not changing my refresh token. Same refresh token is being used to acquire a new access token. And for how long this repetitive calls may continue without any error?
UPDATE AFTER THE TEST
I let my application run on my local machine in Visual Studio DEBUG mode trying to catch any exception, NO Human interaction.
The application kept receiving AJAX calls to Gmail Action with 2 minutes interval, everything was working fine, I went to the gym, came back 2 hours later - oops, Visual Studio debug is open on this Token has been revoked exception, here we go, so it's clear the token was revoked by the Google API service, as you can see from the Debug window. The only question remains - why, since there are no specific details are provided, there is no Inner Exception just that general error message and no reason, but the source is clear - Google API, we can even see it came back from
Google.Apis.Requests.ClientServiceRequest`1.Execute() в
C:\Users\mdril\Documents\GitHub\google-api-dotnet-client\Src\GoogleApis\Apis\Requests\ClientServiceRequest.cs:row
96
I am guessing the service shuts down (revokes a token) after N number of calls, maybe within certain interval. If some one knows the limitations of Google API in terms of number of calls or time intervals between calls, please let me know.
It seems that Matthew Riley, the custodian of Google API on github, coded some logic to revoke a token based on some criteria: https://github.com/google/google-api-dotnet-client
Long response to comment :
One question though: can this be done indefinitely long, unlimited number of times, or I will get an error at some point?
Refresh tokens can be come invalid for the following reasons:
user can revoke it in there google account.
if a refresh token isn't used for 6 months to get a new access token it will expire automatically.
If a user authenticates your application you get a refresh token if they do it again you get a different refresh token. Both will work. you can do this up to 26 times. on the 27 th time the user Authenticates your application the first one you got will expire. You can only have 26 live refresh tokens. (DONT ASK how I know this! "#¤%&)
So assuming you don't reauthentcate your application to many times, use the refresh token at least once every six months. You can use it as many times as you want.
Update for comment:
I think you are still confused. Access tokens expire after 1 hour. Refresh tokens only expire for the above reasons you can use them as many times as you like. To get a new access token.
However you can only have 25 working refresh tokens.
Lets say I have a windows service application that backs up files to a users Google drive account. A user installs it on a server and authenticates it and gets a refresh token. Every night the windows service runs and backs up the files to google drive, it uses the refresh token to get a new access token.
Lets say this user really likes my auto super imba backup service. He installs it on another server. He gets another refresh token and the application goes about its business uploading files at night
Lets say my super user really has a server farm he installs my application on 25 servers. Those applications will be able to get new access tokens forever.
However if this crazy user installs it the 26 th time on a different server getting a new refresh token for this server. The first server they installed it on will stop working because google only allows you to have 25 outstanding refresh tokens for an application.
This is user application based so you can have any number of users each with a max of 25 refresh tokens
http://developer.linkedin.com/documents/authentication (section: Refreshing Access Tokens)
The paragraph says
LinkedIn access token can be refreshed in 60 days time
on the other hand it also says that client application can keep track of token creation date and compare it with oauth_expires_in value (in seconds) and refresh token if required.
However, I get only oauth_expires_in=599 (secs) when I call request token endpoint.
When I retrieve request token:
oauth_token=xxxxx&oauth_token_secret=xxxxx&oauth_callback_confirmed=true&xoauth_request_auth_url=https://api.linkedin.com/uas/oauth/authorize&, here's a response that I get: oauth_expires_in=599
I do not receive such parameter in response to access token request:
https[://]www[.]linkedin[.]com/uas/oauth/authorize/submit?oauth_token=xxx&oauth_verifier=xxx
Can someone please explain this?
P.S.: Altered urls with [] because it didnt allow me to post more than 2 urls due to lack of reputation.
TIA.
The expiry time you're getting in seconds is the expiry time for the requestToken, not the accessToken. In other words, if you don't exchange that token with an access token in the next 599 seconds (10 minutes) , it will expire and you will need to get a new requestToken.
The oauth token you receive has an expiry date of 60 days, per linkedin documentation. I hope this helps.