added /api/auth/tokens endpoint to return oauth tokens #425
Conversation
When using a provider that uses Token ID option (like Apple) a user hitting cancel with no longer cause the app to crash. Users who do this will now be taken back to the sign in page. This was already working for other providers that didn't use this option but wasn't supported for providers that did use it.
…er name on first sign in
* add: marquee provider section * fix: lint * update: adjust node sizes * fix: window undefined SSR * fix: path to imgs Co-authored-by: Iain Collins <me@iaincollins.com>
Includes breaking changes for v3 and updates to documentation. If using the client, the only required change should be setting the NEXTAUTH_URL environment variable.
Passing a redirect function like this is a bit horrible, but is less horrible than before.
* clientMaxAge now passive * clientPollInterval added (works like old clientMaxAge) * poll intervals uses timer (more efficent) * updates state on window focus/blur
Improves how well syncing client state is handled and how well caching is leveraged. Reduces network load, cpu load and memory footprint.
This should never be called server side, but just in case someone calls setOptions server side this prevents it from being invoked at all.
* This is a breaking change in v3 * Includes updated documentation
Unproven, but should fix nextauthjs#395 and improve middleware compatibility.
Accidentally squashed a couple of lines in OAuth callback.
Includes some linter fixes
A method to retrieve OAuth tokens from the database was needed in order to use them with third-party APIs as Bearer tokens.
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/iaincollins/next-auth-docs/7e9dtj6xc |
|
I just noticed that token rotation is not handled so having access to the OAuth refresh and access tokens isn't terribly helpful yet. |
|
@tomvoss Thanks for starting work on this! This is great and we should leave it open for a bit, until we have time to come back to it, if you don't mind? The plan regarding token rotation is has been to handle it like this but call the API for the providers a user has to get a new access token if they existing access token has expired (and if it has, save the new token to the database, with the new expiry time). What isn't clear yet is how many providers return the token in a similar way - basically how many providers will require special handling (probably not many I think) and/or don't actually return tokens. Because going out to a third party service is a blocking call (even if most of the time we can re-use the result from the database) is probably sensible to expose per-provider endpoints (e.g. I don't think we should merge this it in yet, given the above, but maybe in a branch where we can work on that? I think we could build on this to do that! |
A method to retrieve OAuth tokens from the database was needed in order to use them with third-party APIs as Bearer tokens.
|
I went ahead and added the My priority is to work towards automatically renewing expired tokens. My database's accounts.access_token_expires value is null for my Cognito account, but I was expecting it to contain the value returned from the provider with the OAuth tokens. Without integrating other providers into my project I can't know if it's null for other providers. It would be helpful if someone else would check their provider's value. I think this value will be important to know when to proactively renew an access token by exchanging the refresh token. The same is likely true for the refresh token itself. |
|
I see now I probably should have used the plural form and made the endpoint |
|
@tomvoss Thanks Tom! Yes this looks great! Yeah the expires value is currently blank for all providers as it's not saved. I'm very happy to add that to support this! It shouldn't be hard to add I just didn't want to add it without verifying it was going to be stored correctly (i.e. without the date/time getting mangled) and I don't think I had time to test that so left it as is with the expectation of coming back to it. |
|
I didn't expect to get this feature in v3 but given all this work it seems like worth a shot! :-) I'll take a look at fixing what is missing (and doing it for both adapters) over the weekend. Thanks for looking at this! I know there are a lot of moving parts and it's not an easy project to get started contributing to! |
|
The endpoint is now @iaincollins I'm not sure what your thoughts are for renewing tokens, but my first thought was to do something like |
Oooh, that is a great point. Thoughts: I think it's good point to provide a way to clients to forcibly renew but maybe some sort of configurable frequency (and/or be disabled by default with an option to enable) so that people can't spam it and create a Denial of Service vector by triggering too many API invocations - as services like Google and Twitter limit how many requests per hour and per day from an application and the defaults are quite low. As far as default behaviour for the end points, auto-rotating tokens on an HTTP GET if stale (which is technically breaking the RFC expectations of not making changes on a GET request) seems fair use IMO, as returning an Access Token only needs a valid session token and doesn't need CSRF token protection. As with JWT rotation or CSRF tokens I feel like it's an edge case where sticking strictly to the RFC for HTTP isn't in the spirit of user expectation. |
|
@tomvoss Hey, just as aheads up, I've been thinking with all the other stuff going on for v3 I'm thinking we make this the main new feature of 3.1 (not to delay it, just so we can test it in isolation and get it right). I'm hoping we can wrap up v3 and get it out the door this weekend, as it's mostly dependant on change log / release notes to explain breaking changes at this point. I don't think adding this involves any breaking changes, so should be easy to drop it in after, and actually I think in practice we can get it out sooner (as a beta, then release) if we take that approach. Does that sound okay? Thanks again for working on this! |
|
That sounds good to me. |
81a16b9 to
f892dc2
Compare
|
@tomvoss Um sorry I didn't intentionally close this issue! |
|
@tomvoss Ah sorry, it looks like like this happened because the branch was merge to main and also the repo moved form my personal account to an org account for v3 release. For some reason GitHub won't me edit the target branch now. Would you mind re-opening this PR against |
Done. See PR 513. |
A method to retrieve OAuth tokens from the database was needed in order to use them with third-party APIs as Bearer tokens.