feat: complete OIDC support for Apple and Google providers #1108
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hf
commented
May 17, 2023
hf
commented
May 17, 2023
hf
commented
May 17, 2023
hf
commented
May 17, 2023
hf
force-pushed
the
hf/native-oidc-sign-in
branch
from
6ace112
to
f648f04
Compare
hf
force-pushed
the
hf/native-oidc-sign-in
branch
3 times, most recently
from
24955ed
to
a940b32
Compare
hf
added a commit
that referenced
this pull request
May 23, 2023
hf
force-pushed
the
hf/native-oidc-sign-in
branch
from
a940b32
to
0b76c12
Compare
hf
force-pushed
the
hf/native-oidc-sign-in
branch
2 times, most recently
from
53261ec
to
5770b66
Compare
hf
force-pushed
the
hf/native-oidc-sign-in
branch
from
5770b66
to
55b8439
Compare
J0
reviewed
May 24, 2023
J0
reviewed
May 26, 2023
kangmingtay
approved these changes
May 26, 2023
J0
approved these changes
May 26, 2023
hf
force-pushed
the
hf/native-oidc-sign-in
branch
2 times, most recently
from
503608a
to
9ec4370
Compare
hf
force-pushed
the
hf/native-oidc-sign-in
branch
from
9ec4370
to
38482db
Compare
|
would prefer if we had split the support for multiple client IDs in a separate PR - feels like there's already alot going on here |
dshukertjr
reviewed
May 30, 2023
dshukertjr
approved these changes
Jun 7, 2023
|
🎉 This PR is included in version 2.70.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
hf
added a commit
to supabase/auth-js
that referenced
this pull request
Jun 29, 2023
Updates the `signInWithIdToken` API: - No longer experimental. - Adds optional `access_token` parameter. - Updates the types on `provider`. - More docs. To be merged after release of: supabase/auth#1108
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
uxodb
pushed a commit
to uxodb/auth
that referenced
this pull request
Nov 13, 2024
…1108) Previously OIDC sign in (i.e. sign-in using an ID token) for Apple, Google and a few other providers was not properly supported. There was no account linking available, and there were a few security issues found with the implementation. This PR attempts to resolve all of the issues, specifically targeting Apple and Google providers, which enables native Sign in with Apple and Google with mobile or desktop apps. Furthermore, this PR paves the way towards SSO with OIDC support. Basically, the whole `POST /token?grant_type=id_token` endpoint is refactored to use the central `createAccountFromExternalIdentity` method which supports both regular and SSO accounts with automatic account linking. For both Apple and Google flows, the important thing to realize is that their OAuth2 flows are in-fact OIDC authentication flows. The Apple OAuth2 flow already used the Apple OIDC ID token to extract user information. The Google OAuth2 flow is refactored to use the OIDC ID token when available (appears to be always) or fall back to the previous implementation. Since it does not matter whether the flow is OAuth2 or OIDC, automatic account linking can take place. The remaining OIDC supported providers -- Azure, Facebook, Keycloak -- remain supported though with upgraded account linking support; however their implementations are best-effort at this point. Furthermore, the Keycloak implementation should be deprecated as it's actually solving a SSO-with-OIDC problem.
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 13, 2024
…1108) Previously OIDC sign in (i.e. sign-in using an ID token) for Apple, Google and a few other providers was not properly supported. There was no account linking available, and there were a few security issues found with the implementation. This PR attempts to resolve all of the issues, specifically targeting Apple and Google providers, which enables native Sign in with Apple and Google with mobile or desktop apps. Furthermore, this PR paves the way towards SSO with OIDC support. Basically, the whole `POST /token?grant_type=id_token` endpoint is refactored to use the central `createAccountFromExternalIdentity` method which supports both regular and SSO accounts with automatic account linking. For both Apple and Google flows, the important thing to realize is that their OAuth2 flows are in-fact OIDC authentication flows. The Apple OAuth2 flow already used the Apple OIDC ID token to extract user information. The Google OAuth2 flow is refactored to use the OIDC ID token when available (appears to be always) or fall back to the previous implementation. Since it does not matter whether the flow is OAuth2 or OIDC, automatic account linking can take place. The remaining OIDC supported providers -- Azure, Facebook, Keycloak -- remain supported though with upgraded account linking support; however their implementations are best-effort at this point. Furthermore, the Keycloak implementation should be deprecated as it's actually solving a SSO-with-OIDC problem.
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 15, 2024
LashaJini
pushed a commit
to LashaJini/auth
that referenced
this pull request
Nov 15, 2024
…1108) Previously OIDC sign in (i.e. sign-in using an ID token) for Apple, Google and a few other providers was not properly supported. There was no account linking available, and there were a few security issues found with the implementation. This PR attempts to resolve all of the issues, specifically targeting Apple and Google providers, which enables native Sign in with Apple and Google with mobile or desktop apps. Furthermore, this PR paves the way towards SSO with OIDC support. Basically, the whole `POST /token?grant_type=id_token` endpoint is refactored to use the central `createAccountFromExternalIdentity` method which supports both regular and SSO accounts with automatic account linking. For both Apple and Google flows, the important thing to realize is that their OAuth2 flows are in-fact OIDC authentication flows. The Apple OAuth2 flow already used the Apple OIDC ID token to extract user information. The Google OAuth2 flow is refactored to use the OIDC ID token when available (appears to be always) or fall back to the previous implementation. Since it does not matter whether the flow is OAuth2 or OIDC, automatic account linking can take place. The remaining OIDC supported providers -- Azure, Facebook, Keycloak -- remain supported though with upgraded account linking support; however their implementations are best-effort at this point. Furthermore, the Keycloak implementation should be deprecated as it's actually solving a SSO-with-OIDC problem.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously OIDC sign in (i.e. sign-in using an ID token) for Apple, Google and a few other providers was not properly supported. There was no account linking available, and there were a few security issues found with the implementation.
This PR attempts to resolve all of the issues, specifically targeting Apple and Google providers, which enables native Sign in with Apple and Google with mobile or desktop apps. Furthermore, this PR paves the way towards SSO with OIDC support.
Basically, the whole
POST /token?grant_type=id_tokenendpoint is refactored to use the centralcreateAccountFromExternalIdentitymethod which supports both regular and SSO accounts with automatic account linking.For both Apple and Google flows, the important thing to realize is that their OAuth2 flows are in-fact OIDC authentication flows. The Apple OAuth2 flow already used the Apple OIDC ID token to extract user information. The Google OAuth2 flow is refactored to use the OIDC ID token when available (appears to be always) or fall back to the previous implementation.
Since it does not matter whether the flow is OAuth2 or OIDC, automatic account linking can take place.
The remaining OIDC supported providers -- Azure, Facebook, Keycloak -- remain supported though with upgraded account linking support; however their implementations are best-effort at this point. Furthermore, the Keycloak implementation should be deprecated as it's actually solving a SSO-with-OIDC problem.