Bug: JWT returned by signin function can not be used to Authorize

[Ben]

Describe the bug

When using a JWT which was returned by the signin REST endpoint the Authentication fails.

Steps to reproduce

• send a request to the signin REST endpoint of surrealdb with valid root authentication credentials
• Pass the returned token to the Authorization header in a subsequent request
  (Authorization: Bearer <token>)

Expected behaviour

surrealdb should accept the token and return the requested data

SurrealDB version

1.4.2 for linux on x86_64

Contact Details

[e-mail]

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[Gerard Guillemas Martos]

Hi @netcodedev, thank you for reporting this issue. Can you share the error or response that you get upon trying to authenticate with said token against the HTTP REST API?

[Ben]

Hi @netcodedev, thank you for reporting this issue. Can you share the error or response that you get upon trying to authenticate with said token against the HTTP REST API?

Sure. It says "There was a problem with authentication"

[Gerard Guillemas Martos]

Can you provide more detailed steps to reproduce? I have tried and been unable to, here is what I did:

-- In SurrealDB

DEFINE TABLE user PERMISSIONS FULL;
DEFINE SCOPE user SESSION 24h
	SIGNUP ( CREATE user SET email = $email, pass = crypto::argon2::generate($pass) )
	SIGNIN ( SELECT * FROM user WHERE email = $email AND crypto::argon2::compare(pass, $pass) )
;

# In Bash

# Sign up
curl -X POST -H "Accept: application/json" -d '{"ns":"test","db":"test","sc":"user","email":"[e-mail]","pass":"123456"}' http://localhost:8000/signup
{"code":200,"details":"Authentication succeeded","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2MzcxNTksIm5iZiI6MTcxNDYzNzE1OSwiZXhwIjoxNzE0NzIzNTU5LCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiJkZjJhYmJhMy04MmZiLTQ0ZDctODE2Ni04MmU2ZjFhYzgyYTQiLCJOUyI6InRlc3QiLCJEQiI6InRlc3QiLCJTQyI6InVzZXIiLCJJRCI6InVzZXI6dWdwN2xvejhyb3VmZHM5cndncjAifQ.q2I3oTv-OQy0Qw2os5BG1UzC7_W-LCXH_Jf0JJqlghI5Ce-XQScAxClNKK66vWy6fVy9wSvjzsQn8FrOCcmjFA"}

# Sign in
curl -X POST -H "Accept: application/json" -d '{"ns":"test","db":"test","sc":"user","email":"[e-mail]","pass":"123456"}' http://localhost:8000/signin
{"code":200,"details":"Authentication succeeded","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2MzcxNjMsIm5iZiI6MTcxNDYzNzE2MywiZXhwIjoxNzE0NzIzNTYzLCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiJkMDY1ZjAxMy1kOGFhLTRlMDQtODM2Mi0xODc0MmJjOGMyZDciLCJOUyI6InRlc3QiLCJEQiI6InRlc3QiLCJTQyI6InVzZXIiLCJJRCI6InVzZXI6dWdwN2xvejhyb3VmZHM5cndncjAifQ.l6CoEV_X6IPvAViDLahL-SdcwQMBxSLlrPpFQc8S0_XTvgN16mASK8F3OmFe4CNkjFUh8hzF0FSWrknHh1wfBg"}

# Authenticate using token obtained from signing in
curl -H "Accept: application/json" -H "NS: test" -H "DB: test" -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2MzcxNjMsIm5iZiI6MTcxNDYzNzE2MywiZXhwIjoxNzE0NzIzNTYzLCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiJkMDY1ZjAxMy1kOGFhLTRlMDQtODM2Mi0xODc0MmJjOGMyZDciLCJOUyI6InRlc3QiLCJEQiI6InRlc3QiLCJTQyI6InVzZXIiLCJJRCI6InVzZXI6dWdwN2xvejhyb3VmZHM5cndncjAifQ.l6CoEV_X6IPvAViDLahL-SdcwQMBxSLlrPpFQc8S0_XTvgN16mASK8F3OmFe4CNkjFUh8hzF0FSWrknHh1wfBg" http://localhost:8000/key/user
[{"result":[{"email":"[e-mail]","id":"user:ugp7loz8roufds9rwgr0","pass":"$argon2id$v=19$m=19456,t=2,p=1$y9Gg0URJ75yLEAnurDGNLw$dhpuDjE0H1ufY7uOb+Dn7RbSEk9xhNwQLaHHBsglMOM"}],"status":"OK","time":"63.861µs"}]

Is there anything that you are doing differently?

[Ben]

@gguillemas Scope authentication works perfectly. The problem is with root authentication.
If you signin using the root credentials you get back a token. If you then try to authorize using that token, the error appears

# Sign in using root authentication
curl -X POST -H "Accept: application/json" -d '{"ns":"test","db":"test","user":"root","pass":"pass"}' http://localhost:8000/signin
{"code":200,"details":"Authentication succeeded","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2NDAwMDYsIm5iZiI6MTcxNDY0MDAwNiwiZXhwIjoxNzE0NjQzNjA2LCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiJmNzQwZWQ0Ny0yY2NmLTRkMTItODM0NC0zZDEzYTJhOWIwYWUiLCJOUyI6InRlc3QiLCJEQiI6InRlc3QiLCJJRCI6InJvb3QifQ.-3pOs-DwF48Mbh8r4AWtuNUGOuqblZHD60ZOtgdiNlCd_z971eLGvroXyWe_GCaEL6GDgP7Y4K8810mm5xPu2w"}

# Use the token to get date from table
curl -H "Accept: application/json" -H "NS: test" -H "DB: test" -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2NDAwMDYsIm5iZiI6MTcxNDY0MDAwNiwiZXhwIjoxNzE0NjQzNjA2LCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiJmNzQwZWQ0Ny0yY2NmLTRkMTItODM0NC0zZDEzYTJhOWIwYWUiLCJOUyI6InRlc3QiLCJEQiI6InRlc3QiLCJJRCI6InJvb3QifQ.-3pOs-DwF48Mbh8r4AWtuNUGOuqblZHD60ZOtgdiNlCd_z971eLGvroXyWe_GCaEL6GDgP7Y4K8810mm5xPu2w" http://localhost:8000/key/user
There was a problem with authentication

[Gerard Guillemas Martos]

Oh, my bad, I see now 👍

The behavior you are seeing is due to SurrealDB trying to infer the level at which system user authentication happens. We have learned that this is generally not a good idea and have implemented the --auth-level-enabled option on the server, which requires explicitly identifying the level at which authentication is being attempted when a connection is established. This will be the default behavior after 2.0.0, as we consider it a breaking change.

Currently, you have two solutions available:

1. Continue using legacy authentication, but drop the ns and db parameters when signing in as a root user. This is not necessary to authenticate at that level and will prevent the ns and db claims from being present in the token. The fact that those claims are present is what makes SurrealDB infer that authentication is being done at the database level:

# Sign in using root authentication
curl -X POST -H "Accept: application/json" -d '{"user":"root","pass":"root"}' http://localhost:8000/signin
{"code":200,"details":"Authentication succeeded","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2NDA5NTgsIm5iZiI6MTcxNDY0MDk1OCwiZXhwIjoxNzE0NjQ0NTU4LCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiIwMTg3YjJkMC0wNjFiLTQxNDEtOWQ4Ni01ODM5MzNmMjUzMmEiLCJJRCI6InJvb3QifQ.7BYc-CDN3LMlLv5jUMHNJoTrthHkUZGK0aO53V0ylPcXO_aMlnvRuEEznpSHDEs98u3q3SmJac7ON3z0UesP0w"}

# Authenticate using the token
curl -H "Accept: application/json" -H "NS: test" -H "DB: test" -H "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE3MTQ2NDA5NTgsIm5iZiI6MTcxNDY0MDk1OCwiZXhwIjoxNzE0NjQ0NTU4LCJpc3MiOiJTdXJyZWFsREIiLCJqdGkiOiIwMTg3YjJkMC0wNjFiLTQxNDEtOWQ4Ni01ODM5MzNmMjUzMmEiLCJJRCI6InJvb3QifQ.7BYc-CDN3LMlLv5jUMHNJoTrthHkUZGK0aO53V0ylPcXO_aMlnvRuEEznpSHDEs98u3q3SmJac7ON3z0UesP0w" http://localhost:8000/key/user
[{"result":[],"status":"OK","time":"63.639µs"}]

2. Switch to explicit authentication levels on the server by running it with --auth-level-enabled. In this case, your requests will start working without any changes. Keep in mind that you will need to specify the authentication level in your client, with the --auth-level flag in the case of the CLI or the surreal-auth-ns and surreal-auth-db headers in the case of the HTTP API. These headers should be present only if you want to authenticate at the namespace and database levels, and should contain the names of the namespace and/or database that you are authenticating for. I apologize for the lack of documentation around this, I will update the documentation so that users can start testing this new behavior before it becomes the default.

Thank you again for your patience and for taking time to report and follow up on this issue, I appreciate it!

[Ben]

@gguillemas Thank you for that explanation. Since I'm building a surrealdb java lib I'm going to do the 1. option, as using the library should not require the user to alter its database.
The current java library for surrealdb is quite outdated (or at least is the authentication). It seems like scope authentication is not available in it, which is why I developed my own.

[Gerard Guillemas Martos]

I am happy to hear that one of the solution worked for you! I will close this issue then 👍