https://supertokens.com/ logo
Join Discord
Powered by
Hey all. My company is looking to transition over ...
# general
e
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!
r
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 
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.
@emtec here
e
So: 1. the user goes to domain2.com, the system will check if he is logged in, if not it redirects to domain-auth.com 2. here the user logs into the account, and is redirected to the address from the callback parameter. 3. domain2.com application captures the token sent during the redirect, and with it the user authorizes himself in api.domain2.com At this point I understand everything, what about the refresh token? Giving a separate session based on the token sounds logical, but we have no control over account lockout, deletion, password change, etc. At this point in the domain-auth.com API, you need to do additional logic that broadcasts that a given token/user is "not valid", and you need to delete all sessions. Do I understand this correctly?
r
that is correct.
or
you could change the refresh logic on the client apps (on their backend), to check the user's status in the auth backend
and if the user is blocked / deleted etc, just revoke the session.
So no need for broadcast
e
correct
r
@damiankleisinger
e
I have one more question. Sharing sessions between domains is important for us to avoid double login if a user enters from one application to another. Example of use: 1. the user is on domain.com and wants to make a purchase, then an application from domain2.com is opened in the iframe (gateway) (A separate login to the [domain2.com] gateway must also be there, as it will be possible to make this purchase directly on domain2.com, although if someone is coming from domain.com they must immediately be verified as a user coming from domain.com). Question - instead of doing a redirect to auth.domain.com, can I do an embedded login in both applications, albeit when the iframe is loaded (domain.com loads domain2.com [gateway] in the iframe), pass as a parameter this token itself and the application (SPA) reads it for itself? Will this be a safe solution?
Domain.com load Iframe [domain2.com?token={token_from_domain.com}]
r
iframes have a lot of issues in browsers like safari For example, the iframe may not have a session in it, even though the auth.domain.com has a session.
e
Yes I realize this, from 2024 Chrome will do the same. Yet, I don't care about assigning a session (via localstorage or cookie) - I was more concerned with a temporary session when domain2.com (let's call it gateway.com) is fired at domain.com (app.com). Description: 1) User logs in to app.com (here we have embedded login, communication with you to give token) and session is maintained within app.com 2) The user wants to make a purchase and must do so through gateway.com (and must be logged in). So we make a gateway.com iframe in app.com (in the iframe we would add his token from app.com i.e. gateway.com/?token=XXX). We would achieve a temporary access and make sure that the same account is logged in. 3) If the user accesses gateway.com directly (not an iframe), he will have to log in again - which is quite acceptable to me. The question is whether the solution in point 2 is ok, and does it carry any danger?
r
yea, that would be mostly fine. Just that it's not a good idea to add the token as a query param since browser history saves it. But you could send the token over in the iframe message. But otherwise, it LGTM.
e
do u mean postMessage?
r
yea. something like that
e
nice ❤️
thx for sugestion about browser history 🙂
r
@drmp here
20 Views
PreviousNext
Powered by