You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary of proposed feature
We should let users define what protective measures should be taken while logging into an OAuth provider, even if it is a custom one. The options are "state" (using the CSRF token), "pkce" (see the PKCE spec, also, introduced in #941) or "none".
So it should look like this:
{
...
protection: "pkce"// or "state" or "none"...}
We should decide on what should be the default value. Currently state is always checked, except if state: false is set in the options, so protection: "state" seems to be the natural choice here. But is PKCE something we would like to encourage/prefer over state?
Potential problems
As state has been removed in canary, strictly speaking, it MIGHT be a breaking change for custom providers. I can easily add the state option back, and show a deprecation warning in favour of protection: "state".
Describe any alternatives you've considered
In the current stable release of next-auth, a provider can pass an option called state: boolean. This has been removed in the canary in #1022 to simplify the provider options. I was under the assumption that only Apple does not support this, so I hardcoded an Apple specific solution:
thrownewOAuthCallbackError('Invalid state returned from OAuth provider')
}
}
In retrospect, I think it was not a good alternative, but with the new proposed option protection: "none", should fix this. (question. Anyone knows if Apple supports PKCE?)
Interested in what the community thinks!
The text was updated successfully, but these errors were encountered:
Summary of proposed feature
We should let users define what protective measures should be taken while logging into an OAuth provider, even if it is a custom one. The options are
"state"
(using theCSRF
token),"pkce"
(see the PKCE spec, also, introduced in #941) or"none"
.So it should look like this:
We should decide on what should be the default value. Currently state is always checked, except if
state: false
is set in the options, soprotection: "state"
seems to be the natural choice here. But is PKCE something we would like to encourage/prefer over state?Potential problems
As
state
has been removed incanary
, strictly speaking, it MIGHT be a breaking change for custom providers. I can easily add thestate
option back, and show a deprecation warning in favour ofprotection: "state"
.Describe any alternatives you've considered
In the current stable release of
next-auth
, a provider can pass an option calledstate: boolean
. This has been removed in thecanary
in #1022 to simplify the provider options. I was under the assumption that only Apple does not support this, so I hardcoded an Apple specific solution:next-auth/src/server/lib/oauth/callback.js
Lines 25 to 30 in 47a5c9d
In retrospect, I think it was not a good alternative, but with the new proposed option
protection: "none"
, should fix this. (question. Anyone knows if Apple supports PKCE?)Interested in what the community thinks!
The text was updated successfully, but these errors were encountered: