Does anyone know what the expiration period of an OAuth Access Token on GitLab is?
It's at least 12 hours (from experience), but I would like to know for sure so I don't refresh the token unnecessary.
PS: GitLab ... it would be very convenient if the expiration is simply returned when getting/refreshing token (PS: the documentation states that "expires_in": is returned ... BUT IT ISN'T)
from https://forum.gitlab.com/t/missing-expires-in-in-the-token-response/1232/2:
Gitlab uses Doorkeeper for oauth.
The Doorkeeper wiki has an ariticle "Customizing Token Expiration" > https://github.com/doorkeeper-gem/doorkeeper/wiki/Customizing-Token-Expiration2
This wiki tells us a configuration "access_token_expires_in". I > searched in gitlab source code and found it sets to nil.
This meas the 'access_token' will never expire.
Also, this is from https://gitlab.com/gitlab-org/gitlab-foss/-/blob/50d66f5ece57dcfbe074d97703691a8d3c38f4ac/config/initializers/doorkeeper.rb#L42:
# Access token expiration time (default 2 hours).
# If you want to disable expiration, set this to nil.
access_token_expires_in nil
On GitLab, OAuth "access tokens expire in two hours".
Access tokens expire in two hours which means that integrations that use them must support generating new access tokens at least every two hours.
In older versions, OAuth applications could opt-out of access token expiry.
The ability to opt-out of expiring access tokens was deprecated in GitLab 14.3 and removed in 15.0. All existing integrations must be updated to support access token refresh.
2016: It should be 8 hours by default:
lib/gitlab/o_auth/session.rb mentions:
Rails.cache.write("gitlab:#{provider}:#{ticket}",
ticket, expires_in: Gitlab.config.omniauth.cas3.session_duration)
In gitlab.yml, you have:
# SSO maximum session duration in seconds. Defaults to CAS default of 8 hours.
# cas3:
# session_duration: 28800
2022: the Expiring access tokens documentation mentions:
no more opt-out of expiring access tokens since GitLab 15.0 (June 2022)
Access tokens expire in two hours which means that integrations that use them must support generating new access tokens at least every two hours.
Related
I've been working to setup Oauth communication for an auto-emailing node.js web app using nodemailer. (I don't wish to use gmail's Less Secure Apps setting).
I've taken steps to get the client id, secret, and refresh token from the oauth playground, and have set up the web app to use a stored refresh token to request new access tokens when it first loads.
It is able to send emails (for about 7 days), then I get error invalid status code 400 on client side, and/or invalid grant on server side.
Going back to google playground and getting another refresh token, then updating it in environment variables, solves this for another week. But I'd like to solve this indefinitely.
I read somewhere "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"... so last week I switched the app to "In Production" (at console.cloud.google.com) and tried having it verified with google. This week, the same issue has recurred suggesting that wasn't the right fix, or that it wasn't yet verified with google.
I don't know if this was done correctly, nor do I know if this is the true solution to this expiring/revoked refresh token, or invalid grant.
I've also come across these explanations:
The user has revoked your app's access.
The refresh token has not been used for six months.
The user changed passwords and the refresh token contains Gmail scopes.
The user account has exceeded a maximum number of granted (live) refresh tokens.
The client has reached a limit of 50 refresh tokens per account if it's not a service account.
(I didn't make ANY changes during the week, so...not sure why these would have changed)
Is the issue the refresh token?
Or the status of the application?
Would it be dns/cname/cloudflare server issues?
For those who have the same issue in the future:
It turned out that google verification wasn't necessary.
It seems like the refresh token expiring after a week or 7 days was due to the placement of the oauth2Client.setCredentials() function call and accessToken variable.
Calling setCredentials() and obtaining the access token INSIDE the SendEmail() function (at runtime, just before sending email, rather than at application start/spinup time) seemed like it enabled the code to more dynamically generate the tokens it needed. After 12 days, it still seems like its working so I'd call this a success.
My guess at why it wasn't working before was because setting credentials outside of a function meant that code only ran once on server/application startup. It would then store the obtained access token in a const.
The access token would eventually expire, and even if called again/later inside of a function to obtain a new access token, it would be unable to change the value of a const property/variable, and so the call would inevitably fail after a week when it failed to renew.
Hope this helps anyone else having a similar issue.
My apologies for the run-on sentences.
There are a lot of causes for invalid grant it sounds to me like your refresh token is expiring.
If your project on google developer console is still in testing, has not been moved to published and has not gone though the google application verification process then refresh tokens have a max two week life span after which they will expire which may explain your invalid grant. The thing is there is no official word from google that this is happening its just what a lot of developers are seeing these days.
Another one is with gmail scopes if the user changes their password this will also cause the refresh token to expire.
I’m implementing APNS Token based authentication using pushy Java library right now but there is one unclear part in Apple’s and Pushy’s documentions.
I will have several severs sending push notifications with pushy using Token based authentication.
What’s troubling me is the part in Apple documentation stating:
For security, APNs requires you to refresh your token regularly. Refresh your token no more than once every 20 minutes and no less than once every 60 minutes. APNs rejects any request whose token contains a timestamp that is more than one hour old. Similarly, APNs reports an error if you recreate your tokens more than once every 20 minutes.
So the part that I’m afraid is the “no more than once every 20 minutes”. If I have let’s say 4 severs and each generate a token every 50 minutes using the same signing key, will I be constantly in this limit? Unless this limit applies to each TLS connection maybe.
Do I have to build a way to share tokens across servers, if so can Pushy be configured with a token directly? or should I use a different signing key for each server?
I'm requesting an access token via Azure AD, using the address:
https://login.microsoftonline.com/{TenantId}/oauth2/v2.0/token
The token returns correctly, however, the default lifespan of the token is 1 hour. Looking at the Microsoft documentation, there doesn't appear to be a parameter I can pass to request a token with a custom lifespan.
Is it possible to request a token with a short(er) lifespan?
Yes, you can configure your Azure Active Directory token lifetime minimum 10 minutes.
You could use following power-shell command to create your token lifetime policy.
$policy = New-AzureADPolicy -Definition #('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00","MaxAgeSessionSingleFactor":"00:10:00"}}') -DisplayName "WebPolicyScenario" -IsOrganizationDefault $false -Type "TokenLifetimePolicy"
For more details you could have a look these official docs.
Note
Configurable token lifetimes in Azure Active Directory is now in (Preview) which is not recommended to use on production
We have an OAuth/OIDC service developed in API Connect/Datapower.
When a user requests a new refresh_token - if any unexpected error occurs in the flow, the new refresh_token is not issued, and their existing refresh_token is revoked. This forces the user to go through a new consent flow. This can be problematic if large numbers of customers are affected due to some unexpected error. We would like the old refresh_token to still be valid in this scenario.
We raised this with our IBM support contact - and he said this works as intended (i.e. - it should revoke the old refresh_token as the first action - it is single use, regardless of outcome).
He did suggest that it is possible to configure the refresh_token to be used multiple times until it is revoked/expired.
I am not sure how to do this - or what versions it is supported in. He said '(in 2018.4.1.x)? For v5 gw, use extension to enable it, You will need the latest DP firmware release for the above'. It's been hard to get any clarity on this. The IBM developer forums even directed me to Stack Overflow...
Does anyone have any more information/experience with enabling a refresh_token to be used multiple times? Or what versions this is supported in (or links to any documentation about this)? I'm struggling to find anything concrete on this.
Thanks
I suppose he's talking about the count configuration. it is located just below Enable refresh tokens.
Section 'OAuth 2' -> Tokens -> Enable refresh tokens -> count
Hope this could be helpfull
For IBM API Connect version 2018.4.1, you can specify whether the refresh token for OAuth provider is One time use only or not.
See OAuth native provider>Tokens screen.
After an access token expires, if the option is enabled in the OAuth provider API, the application can use refresh tokens. Each refresh token is valid for approximately 31 days after it is issued and can be used only once to request a new access token. Along with the new access token, a new refresh token is also returned.
I just started using WSO2 IS version 5.0.0 with SP01 installed. I have configured a relying party and I am attempting to use the Open ID Connect/ Oauth 2.0 protocol in order to authenticate my users using a read-only LDAP.
The documentation states that we can control the expiry time of in the following XML configuration tags found in PRODUCT_HOME/repository/conf/identity.xml
<!-- Default validity period for Authorization Code in seconds -->
<AuthorizationCodeDefaultValidityPeriod>300</AuthorizationCodeDefaultValidityPeriod>
<!-- Default validity period for user access tokens in seconds (default: 3600) -->
<AccessTokenDefaultValidityPeriod>60</AccessTokenDefaultValidityPeriod>
<!-- Default validity period for application access tokens in seconds (default: 3600)-->
<UserAccessTokenDefaultValidityPeriod>60</UserAccessTokenDefaultValidityPeriod>
<!-- Validity period for refresh token -->
<RefreshTokenValidityPeriod>84600</RefreshTokenValidityPeriod>
<!-- Timestamp skew in seconds -->
<TimestampSkew>300</TimestampSkew>
<!-- Enable OAuth caching -->
<EnableOAuthCache>true</EnableOAuthCache>
I have set both the AccessTokenDefaultValidity and the UserAccessTokenValidity to be 60 instead of 3600 but it seems that the WSO2 IS application does not expire them in the time that is set.
Also I am using the PASSWORD grant type to create the Access Token.
To test this I am using a Java client written to contact the server and send the username and password. This works fine as it generates the access Token.
This is the response from the WSO2 IS server (minus the id_token for security):
{"scope":"openid","token_type":"bearer","expires_in":0,"refresh_token":"a3699846516d7c39c24fea76171bd41", "access_token":"88286cb21f3a9888945eb806f8abcef"}
I think the expires_in is wrong because it says 0 seconds, in otherwords my generated tokens should expire immediately. Based on my configuration I would expect it to say 60 seconds.
After waiting approximately 1+ minute, I can still use the access token to get my id_token and therefore the protected claims again, even though it should be expired as per the xml configuration.
Note: I am not using WSO2 IS APIM, this is only for the IS product.
Thanks for your time