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

Oauth: create or login oauth account via token #254

Open
alee-candy opened this issue Apr 1, 2024 · 5 comments
Open

Oauth: create or login oauth account via token #254

alee-candy opened this issue Apr 1, 2024 · 5 comments

Comments

@alee-candy
Copy link

Authn supports oauth accounts strictly through the use of their redirect URIs which handle the authentication flow of the third party provider and creation/authentication of users in authn server. This solution works when redirecting the user from a web app but causes multiple issues when used in an ios/android app.
These issues include:

  1. Due to Google and Apple's Policy regarding Login Process via webview, this immediately raises a high risk of being rejected. Though we attempted to find a way to circumvent this risk, it is proving to be difficult.
  2. Using this method makes it extremely difficult to implement the face recognition (FaceID) and fingerprint verification within the application for Social Login.

Proposed solution:
Create a HTTP POST endpoint that takes in a provider name and a provider's oauth token. It will then follow the same steps as the oauth flow where it calls the provider to verify the token and gets the user info, reconciles the users identity into an oauth account, and creates a session. This endpoint will be private.

POST /oauth/:providerName/import

providerName can be any of the existing supported oauth providers as it won't need any additional provider specific implementation.

@cainlevy
Copy link
Member

cainlevy commented Apr 1, 2024

This endpoint will be private.

Do you mean that it would be called by the application's backend? Would it make sense for this endpoint to be called by the client, much like the normal redirect? I'm sure there's something subtle I'm overlooking here.

@alee-candy
Copy link
Author

I thought making the endpoint private would make it more secure but you're right that makes sense. I can make it public.

@alee-candy
Copy link
Author

alee-candy commented Apr 8, 2024

@cainlevy - do you know if there is a particular reason we keep the access token on the oauth accounts table? I'm not seeing it used anywhere other than in the first request to get user info.
I'm hoping I might be able to come up with an implementation where we can get the id token from the FE and use a different validation endpoint using that token to get the user details. I would need to remove the not null constraint on that column in order to support this other implementation.

@cainlevy
Copy link
Member

cainlevy commented Apr 8, 2024

Yes my plan was to eventually make it available to the host app for any extended APIs that may be available with the token. That idea hasn't gone anywhere.

@AlexCuse
Copy link
Contributor

Do we know if all the supported providers will have the necessary info in the ID token? It may be available in 'extra' on the oauth2 token but most of the providers are calling an additional API with a config that gets seeded from that token to get the email.

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

3 participants