Hey all My company is looking to
# general
Hey all. My company is looking to transition over to SuperTokens. After looking at some things we see that our current auth solution uses PKCE, but it appears that SuperTokens does not support OAuth 2.0 flows, but that does not seem quite right to me. Would someone be able to point me towards the proper documentation to answer this question?
I assume we can implement our own solution if this isn't provided out of the box, but would like any additional context if possible!
hey @EJ . Thanks for the question. I believe that @Adiboi has replied to this on your DM.
Hey! You can implement the implicit flow with supertokens until we release full OAuth 2.0 support (1-2 months time). Let's take an example of two sites - auth.com (having the auth form), and client.com: - User visits client.com and they have no session. - client.com redirects the user to auth.com (which uses our frontend & backend SDKs) on auth.com/auth?redirect_to=https://client.com/callback. On this page, the supertokens SDK will show the auth UI (if you are using our pre built UI), or you can build your own UI (using supertokens-web-js SDK). Either way, you should store the redirect_to query param somewhere. You should also validate that the redirect_to uri value is an allowed one. - The user logs into auth.com as usual and we now have a session on auth.com for that user. - Post session creation, you should redirect the user to client.com/callback (based on the redirect uri) along with the access token - like clilent.com/callback?access_token=..... The access token can be fetched on the frontend from our frontend SDK's
function. - Once on client.com/callback page, you should extract the access token from the query param, and send it to the backend of client.com. Let's call this backend api.client.com - api.client.com then verifies the access token using any jwt verification lib (querying the jwks endpoint from the auth.com's backend). - post access token verification, client.com can create its own session to keep the user logged into that site. Note that this approach will only work if all the client.com sites are controlled by you. Once we have oauth 2.0 features, you can easily replace this with the standard Auth code grant flow via PKCE / client secret.