-
Notifications
You must be signed in to change notification settings - Fork 5.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support differing expiry of identity vs authorization OAuth tokens #24815
Comments
Which provider is it that you're seeing this for? The token being revoked is something that shouldn't happen regardless of whether we have backend storage or not. Agree that that would be a good addition though 👍 There are some potential fixes for this on the way in #24743 too, I spotted some bugs for the refresh endpoint of some providers as part of that refactor. |
I see it for GitLab provider. |
We are using the ID Token from GitLab to request some third party API and calling the |
It's not technically possible to do it in background. And besides, even if it were possible, as reported at the top, that might even more aggressively revoke other ongoing token flows causing problems elsewhere right? It sounds to me like this is a serious limitation in how gitlab does token handling in general. Any pointers or assistance in making this better is appreciated 🙏 |
I checked the responses from Gitlab. The ID token has an expiration time of only two minutes. But the expiration date returned in the response is 120 minutes. The access token is also 120 minutes valid, if not revoked by a refresh. How often does Backstage refresh the token? If I understood it correctly, it will be refreshed only 5 minutes before it's expiration. This would mean after 115 minutes. At this time the ID token will always be expired. EDIT: What would help us? |
It chooses an expiration that's capped by the access token expiry yes, to ensure that the refresh happens before it expires. So five minutes before that. We don't look at the expiry time of the identity token as far as I can recall. Either way, two minutes is extremely short - I'm not entirely sure what's best to do here. Should we refresh it every minute in the background for example, whether it's used or not? That would be pretty aggressive and since each refresh kills any OTHER tokens that were issued for other purposes elsewhere, I worry that it would lead to problems in other places whose tokens would start to effectively become flaky. At this point in time I don't think we have any great path forward for this. Potentially we could put code in place that ends up computing the refresh time to 1 minute 45 seconds or whatnot, instead of 120 seconds. That could be a contribution to the project if somebody is up for it, but I do worry about the implications of it. The even more complex path forward would be to make the code smart enough to only ask for refreshes if the specific token being asked for is near its expiry, i.e. making effectively two different expiry timestamps. Then those who never call Removing the RFC state and making it a feature request instead. |
Thanks for your research. We decided to use a Yarn patch as a hotfix like this:
Of course this is pretty hacky in |
It appears that there is an intention of having separate provider checks in the
I'm adding a |
Hi there, in conversation with @Rugvip, our initial recommendation would be adding a logic in the frontend that checks the expiration if the token is JWT token. Let us know if you have follow-up questions 🙂 |
🔖 Need
Current issue:
If to open Backstage in 2 different tabs and perform
ScmAuthApi.getCredentials
in each tab, the token on tab 1 will be revoked. The problem lies that the session lives only in memory and the session manager doesn't reuse it.It's not unique when users can open Backstage in multiple tabs or in different browsers, in order to perform different scenarios in each browser session.
🎉 Proposal
The proposal is to store the OAuth session in the database, for example in
backstage_plugin_auth
database in a new tableoauth_session
or something like this.〽️ Alternatives
No response
❌ Risks
Such tokens are short lived, i.e. GitLab token can be valid maximum for 2 hours.
👀 Have you spent some time to check if this RFC has been raised before?
🏢 Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: