https://supertokens.com/ logo
Join Discord
Powered by
For this question let's say I have two microservic...
# support-questions-legacy
a
For this question let's say I have two microservices A and B. I have two scenarios: API Gateway: A and B do not have to worry whether the user is logged in or not. The API Gateway is the single source of truth for them any request that passes through gateway is assumed to be authenticated and authorised. How should I implement supertokens in this case. A and B wants the requests to be authenticated: If A and B are to do session verification independently and If I use supertokens SDK in both of them won't the SDK expose its endpoint in both the application? And suppose I grew to 5 microservices then will I have to add boilerplate code of SDK in all 5 of them?
r
hey @aV
a
in my case the api Gateway verifies jwt only
r
> API Gateway: A and B do not have to worry whether the user is logged in or not. The API Gateway is the single source of truth for them any request that passes through gateway is assumed to be authenticated and authorised. How should I implement supertokens in this case. You should enable the JWT feature in session.init on the backend, and then extract the JWT from the session on the frontend and pass that in each request header. You can find docs about this here: https://supertokens.com/docs/session/common-customizations/sessions/with-jwt/about
a
Also which method is fast using SDK or JWT verification.
If I use JWT, the supertokens csrf protection, automatic session refresh etc will work the same only I can't revoke the session immediately and have to wait untill the JWT actually expires right?
r
> A and B wants the requests to be authenticated: If A and B are to do session verification independently and If I use supertokens SDK in both of them won't the SDK expose its endpoint in both the application? And suppose I grew to 5 microservices then will I have to add boilerplate code of SDK in all 5 of them? I assume that here you do not want the API gateway to do auth. And in all the microservices that are exposed to the frontend (so that the browser can call their API), you will need to use the session recipe in them. If there are microservices that are not exposed to the frontend, you do not need to do supertokens.init in them, and can directly verify the request from other microservices in the following ways: - The user's session handle is passed in the request -> you can query the supertokens core and verify the session handle (this will require session.init). - You can JWT in the session, extract the JWT from the session and pass that to the microservice (this will not require use of supertokens SDK in those microservices). - You can make your own method of auth to communicate between the microservices.
> If I use JWT, the supertokens csrf protection, automatic session refresh etc will work the same only I can't revoke the session immediately and have to wait untill the JWT actually expires right? Yes. You can change the access token's lifetime though to make it smaller. You can also add the sessionHandle to the JWT, and in your services that are behind the API Gateway, you can get the sessionHandle and query the core to check if the sessionHandle still exists. If not, you can return a 401
a
OK as per your response I have make up my mind like this. The API Gateway will check if sessionHandle is attached with the request if not reject the requests immediately. If sessionHandle is provided then pass on the requests to the responsible microservices. The microservices will will post a request to /recipe/session/verify of the core passing in the session passed from the api gateway. If core returns 200ok then process the request otherwise pass 401 to the gateway. Is this flow correct?
r
Well, an easier option here would be to just not have the API gateway do auth at all. And use our SDK for session verification in the server code.
Cause anyway if you are making the micro service query the core, you might as well use our SDK there
If you want the API gateway to do auth, then you should just rely on the JWT auth that it has and then don’t do any verification in the API code at all.
And if you are ok with having verification code in the API layer, then might as well use our SDK there and then no need to make the API gateway to verification.
a
In this I will go by the first approach (session.init). Can you share a code snippet to implement the same in golang.
r
And you can use this function to check if a sessionHandle exists on the core: https://pkg.go.dev/github.com/supertokens/supertokens-golang@v0.8.0/recipe/session#GetSessionInformation
a
So I will make a new microservice responsible only for supertokens that will provide endpoints to the frontend. In order to do session verification from other microservices I will use getsessioninformation function and if this returns ok I will process the request otherwise reject. Now is this approach ok?
Anyway let me do the implementation and will notify you. Thanks for awesome support
r
that can work, yes.
a
One more request can you write a blog or give some information comparing ory and supertokens. I just shifted from ory because I find it hard to implement on frontend side. Though on Backend it was breeze.
Only if you have time 🙂
r
Well, we may write one eventually, but a short comparison is that we are easier to customise. If you want to make any change to the backend logic for how auth works, you can simply do so on the backend SDK side (using the override feature). On the frontend side, we give you a react SDK, which has all the auth related components which you can embed in your website however you like. You can change the themes, CSS, and even override the react component tree to add custom UI elements in the forms.
a
hmm... the only downside I see right now is the core which consumes lot of memory on my laptop. Ory binaries were just 12MB. Though in your readme it's mentioned that in the future it will be fixed.
r
yup. We do intend to use GraalVM which will make it consume lesser memory. Right now, it depends on Java's Virtual machine
7 Views
PreviousNext
Powered by