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?

hey @aV

in my case the api Gateway verifies jwt only

> 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

Also which method is fast using SDK or JWT verification.

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

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?

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.

In this I will go by the first approach (session.init). Can you share a code snippet to implement the same in golang.

CHeckout this recipe: https://supertokens.com/docs/session/introduction

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?

that can work, yes.

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.

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.

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.

yup. We do intend to use GraalVM which will make it consume lesser memory. Right now, it depends on Java's Virtual machine