This is how implicit flow can be implemented:
- Let’s say we have client1.com and auth.com. client1.com wants to login using SSO via auth.com. auth.com has integrated with supertokens (frontend + backend SDK + core).
- user visits client1.com and they are not logged in (using our frontend SDK you can check if a session exists on client1.com). User clicks on the login button. The login button redirects the user to auth.com?redirect_uri=
https://client.com/callback (notice the redirect_uri query param here).
- auth.com validates that the redirect_uri is known to it (via an API call to the backend). At the moment, this API would need to be implemented on your end and would require you to maintain a list of accepted redirect_uri . If the redirect_uri doesn’t match, show an error. If it does match, save the redirect_uri in localstorage.
auth.com then shows the login screen and the user signs in as usual (via the usual supertokens guides flows). Post login, they have a session on auth.com. Make sure that this session is using the JWT feature.
- The frontend can then extract the JWT from the session and redirect the user back to redirect_uri with the jwt like this: client1.com/callback?token=…., where the value of token is the jwt. This is the key part in the implicit grant flow.