Skip to content
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

Use refresh tokens for OAuth #1377

Open
nsarrazin opened this issue Jul 29, 2024 · 4 comments
Open

Use refresh tokens for OAuth #1377

nsarrazin opened this issue Jul 29, 2024 · 4 comments
Labels
back This issue is related to the Svelte backend or the DB enhancement New feature or request

Comments

@nsarrazin
Copy link
Collaborator

Currently we use long-lived sessions that get extended when the user performs an action. In order to better manage sessions, we could switch to an OAuth flow where we have a short lived session with an access token cookie and a refresh token that we can use to refresh the sessions, since HuggingFace now supports refresh tokens.

We would probably need to make this flow opt-in in the config as I'm not sure every oauth provider supports this ?

relevant: #1365 (review)
cc @coyotte508 if you have any resources on how to implem this, I've never done it before 👀

@nsarrazin nsarrazin added enhancement New feature or request back This issue is related to the Svelte backend or the DB labels Jul 29, 2024
@coyotte508
Copy link
Member

hmm well basically in the oauth response, besides userinfo, you have an optional refresh token. And also the oauth token expiration date, and refresh token expiration date.

So, you need to store in the session both the oauth token and the expiration date.

When the expiration date is close (eg half of the oauth token duration), you can use the refresh token to create a new oauth token and store it in DB in the session's document.

The more tricky part is refreshing the refresh token. It will only work, once, and you need to store the new refresh token in DB. The old token won't be valid anymore.

I would suggest refreshing the refresh token at the next opportunity once it's a month old. Since the sessions last two weeks, there's no risk of a session with an expired refresh token (they last three months, at least with HF).

If refreshRefreshToken fails, it should update the session to make the next try in an hour, to avoid a failing API call every single request . Make sure to do db.session.updateOne({_id:..., refreshToken: <old refresh token>}, ...) so that a concurrent refresh is not overwritten by the failed one.

When the oauth token cannot be refreshed and expires, the session should probably be removed from DB.

Probably got in more details than needed 😅

@dlavrenuek
Copy link
Contributor

The more tricky part is refreshing the refresh token. It will only work, once, and you need to store the new refresh token in DB. The old token won't be valid anymore.

The refresh access token request will also return the refresh token*, there is no separate request to renew the refresh token (at least not in the spec). If HuggingFace IDP always returns a new refresh token, then always setting both tokens on login/refresh makes sense.

* it depends on the identity provider implementation. Some IDPs always return a new refresh token, some only return it if the expiration time of the old one is short. Also some useful info: some IDPs return the refresh token as JWT but some just return a formatles string, it means that expiration date of the refresh token might not always be known.

@coyotte508
Copy link
Member

coyotte508 commented Jul 29, 2024

Yes my bad, the same call refreshes both the access token & refresh token.

@solanki-aman
Copy link

solanki-aman commented Sep 13, 2024

Currently looking into the same issue and I came across this thread. Circling back for any updates on this? @nsarrazin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
back This issue is related to the Svelte backend or the DB enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants