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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to raw SSO response #187

Open
jpw opened this issue Nov 26, 2023 · 1 comment
Open

Access to raw SSO response #187

jpw opened this issue Nov 26, 2023 · 1 comment

Comments

@jpw
Copy link

jpw commented Nov 26, 2023

Hi there,

Firstly, many thanks for this library, it looks very useful 馃檪

In a client application of this library, I can imagine two ways of knowing when to request a new token:

  1. wait for a 401 response, request new token, re-run original request.
  2. maintain token expiry time in the local state, and when that time is past, request new token.

With the API that I am using, on refreshing a token, the SSO response includes an expiry time as well as a new token. So I would like to use method 2 (and I suspect many API maintainers would prefer 2 was used as well 馃榿), but I can't see a way of accessing the result of the SSO response to get at this new expiry time.

Additionally, the SSO API may return a new refresh token as part of a policy of enforcing rotation of refresh tokens, so I need to get at that data as well. In any case, I think having the choice would be nice.

Perhaps I am over looking something! But any thoughts much appreciated, thanks.

@fiznool
Copy link
Owner

fiznool commented Nov 26, 2023

Hi, thanks for bringing this up.

I think we can probably agree that for any client library, you'll need to implement 1), as the API is the source of truth. With this in mind, I've always considered 2) as a nice-to-have - saving a round trip to the API, perhaps, or enabling some other intelligence around refreshing tokens.

With this in mind, I've always had to implement 1), and then moved on to something else, never actually implementing 2). That is probably still my stance today.

That being said, I understand that this can be useful. I don't have the resources at present to implement something like this, but if you'd like to propose how this could work, then I'm all ears. 馃憘

In other words - PRs welcome! 馃檪

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants