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! 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

Session.getAccessToken

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.