or installed core manually?

docker

ok. Have you set the API key in the docker env vars?

supertokens/supertokens-sqlite:2.5

when running the docker run command?

no in the conf.yaml which I pass to the container

ok, so it's in the config yaml then?

if so, can you please remove it from there (comment that property out), and try to call the createNewSession again (without apiKey being set in the go SDK). Do things work then?

It works without the key! Sorry, now I feel dumb 😄 should have thought of that 😅

No.. don't worry about it. But if you have specified the key in both the places, it should continue to work

Can you show me how you have specified the key in the config.yaml file?

(with an example key)

api_keys: "Akjnv3iunvsoi8=-sackjij3ncisds,asnj9=asdcda-OI982JIUN=-a"

okay. And what have you specified in your go SDK?

supertokens.Config(supertokens.ConfigMap{
        Hosts:  s.Config.SuperTokens.Hosts,
        APIKey: s.Config.SuperTokens.APIKey,
    })

I will double check in the debugger whats in the Config struct...

As a heads up, in the config.yaml, you have given two keys. One is

Akjnv3iunvsoi8=-sackjij3ncisds

and the other is

asnj9=asdcda-OI982JIUN=-a

. They are comma separated. So in the go SDK, you should give only one of them. That is

s.Config.SuperTokens.APIKey

should be

Akjnv3iunvsoi8=-sackjij3ncisds

or should be

asnj9=asdcda-OI982JIUN=-a

.

Ahhh... now I see.... 🤣 the comma is a separator and not part of the key! I conveniently used your example key for my dev setup and didn't realize that these are two keys! 😄

Ahhh i see. Our bad. We should make this more clear somehow. Will do.. Thanks for the feedback

lmk if it works now with the keys being used

give me a sec (or two...)

up and running fine! 😄 thx a lot for your patience 🙂

awesomeeee!!! happy to help.

Hi, I am considering a move from Auth0 to Supertokens. I can't find on the documentation information on published JWKs, where can I find this information?

Hi @User . Our session management is slightly different compared to auth0's: - We do not issue open ID tokens after login as we do not have features like SSO. A successful login simply yields a session using httpOnly cookies. - This session is governed via an access token (which is a JWT) and a refresh token (which is not a JWT). The access token is not an open ID token and should not be treated as such. - We also abstract away the managing of sessions completely so that you do not have to worry about things like verifying the access token yourself.

Therefore, you do not need access to the public key use to verify the access token. It happens for you within our SDK itself.

In our case we are using Hasura, which requires us to read the key to validate with out authorization rules, and Hasura needs to connect to it from a public url. If that's possible to do, then I see it's a very smooth migration for us 🙂

So when you say "read the key to validate", is Hasura verifying the incoming session for each API request and then passing the user info to your APIs?

No, currently Auth0 does that. Hasura needs the key to decode the JWT token to validade if it's a valid token only for requests that are behing authentication. User info are embedded in the JWT token for now.

Understood. Is there a way to disable that feature in Hasura and do token validation within the API itself? The end effect will be the same that if a user calls an API which needs a session but the user has not provided one, they will get a 401 error

That could be done, just will give us a bit more overhead as we'd have to create an intermediate service for just connecting Hasura with Supertokens. Not a big deal, but doable.