See Cognito's advice as well: https://aws.amazon.com/blogs/mobile/understanding-amazon-cognito-user-pool-oauth-2-0-grants/#:~:text=Authorization%20code%20grant,it%20for%20the%20desired%20tokens.

"The authorization code grant is the preferred method for authorizing end users. Instead of directly providing user pool tokens to an end user upon authentication, an authorization code is provided. This code is then sent to a custom application that can exchange it for the desired tokens. Because the tokens are never exposed directly to an end user, they are less likely to become compromised."

So it all comes down to how much you care about your user's security.

What is your service name? So that I have better context of this conversaiton.

I'm not sure that really helps

Ah I see.

It sounds like the suggestion is to have a specific service running just to integrate with Auth0, and once we did that we would integrate with super tokens. But honestly I really dislike the idea of writing the service in the first place

> I really dislike the idea of writing the service in the first place Integration with Auth0? Integration with supertokens? or both?

integration with Auth0

I mean we too need to do that hahaha

we are using the access tokens generated by the user to access our services

cause it's all linked.. Auth0 for login + user managenent session layer authorisation layer

> we are using the access tokens generated by the user to access our services Why?

why not?

it's easy to do that

Shouldn't u be issuing an access token for that user to access your service

what do you mean, auth0 issued the token for the user, that's the auth for our service

I see. So if tomorrow Auth0 decides to change their token structure, you too have to make a change?

And if someone is not using Auth0 etc.. how do they use your service?

our service supports any provider that is OIDC complaint

so sure we support any standard, and if that standard changes, yes we would have to make a change, but that hasn't been hard so far

I'm not sure Auth0 could change in a meaningful way that would impact us, could you talk more about that?

No i mean if you are supporting a standard, that is OK

So you have to tell your customer to give you the OIDC token issued by their login provider.

yes

And store that in the session information

we are not a login provider. We just do sessions

1) So their login provider wil give them an OIDC token 2) They identify the user from that token on thier backend 3) They create a session using that user's userID and store the OIDC token in the session 4) To use authress, they extract the OIDC token from the session token on each API and use authress using that OIDC token as usual.