Open alee-candy opened 7 months ago
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.
I thought making the endpoint private would make it more secure but you're right that makes sense. I can make it public.
@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.
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.
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.
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:
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.