JWT authentication - HTTP 403 - Invalid credentials - `strapi develop`

[zurfluh]

Describe the bug
When running Strapi with a custom JWT_TOKEN, login works and returns a JWT. Using this JWT to authenticate API requests results in HTTP 403 with the message "Invalid credentials".

The only way for me to avoid this is to delete jwt.js and let Strapi auto-generate the file. As soon as I change the file, authentication breaks again, and can again only be fixed by deleting jwt.js.

Steps to reproduce the behavior

1. Create jwt.js exactly as per https://strapi.io/documentation/v3.x/plugins/users-permissions.html#security-configuration
2. Start Strapi strapi develop
3. UI: Create user, add to predefined "Authenticated" group. Allow "Authenticated" to "find" on the resource.
4. Log in - POST /auth/local . Succeeds and returns a JWT.
5. GET /my-resource with header "Authorization: " returns HTTP 403, "Invalid credentials".

If Step 1. is omitted and jwt.js is deleted instead, the bug does not happen.

Expected behavior
GET /my-resource returns HTTP 200 and data, like what's described before when the jwt.js is re-generated.

Screenshots

Code snippets
jwt.js

module.exports = {
  jwtSecret: process.env.JWT_SECRET
};

I verified that JWT_SECRET is set.

System

• Node.js version: v10.16.3
• NPM version: v6.13.4
• Strapi version: v3.1.3
• Database: PostgreSQL
• Operating system: linux

[csotiriou]

I had the same problem. I had accidentally set theJWT_SECRET as key to the admin server in server.js and inside jwt.js. I have verified from the Strapi code that if you use the same secret for both the admin interface and the REST API, Strapi thinks that all requests must go through the "admin api" routes, and you get a 403 due to bad permissions.

The fix was to use JWT_ADMIN_SECRET inside server.js, and JWT_SECRET inside jwt.js

This should have been documented, in my opinion.

[zurfluh]

Thank you @csotiriou, your suggestion fixes the issue.

If this behaviour you are describing--"all requests must go through the admin api"--is neither intended nor is of any use, I would still like this bug to be fixed. Of course having separate secrets is better. Strapi could at least print a warning if the two secrets are the same, or fail to start up. I'd appreciate anything more explicit than the current "silent failing".

[muditjuneja]

Changing the secrets worked. Agreed with @zurfluh point. This should be fixed.

[WEEFAA]

This should be fix. 🎬

[derrickmehaffy]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/invalid-credentials-for-authenticated-users-via-api-usage/5759/5

[robbyemmert]

I figured out the root cause of this issue after about 3 days of debugging:

Check out this file: https://github.com/strapi/strapi/blob/86e0cf0f55d58e714a67cf4daee2e59e39974dd9/packages/strapi-admin/middlewares/auth/index.js

The above middleware runs on every request. It assumes because it can verify your JWT with the admin secret, that you should be an admin, looks up your admin user with your users-permissions_user id (super dangerous) and since it won't ever have the right role, fails.

The bottom line is if JWT_ADMIN_SECRET happens to equal JWT_SECRET, requests will fail...mostly. Requests will still succeed for users where there happens to be a strapi_administrator with the same id as their user-permissions_user.

In my opinion, this should be documented and then fixed. We need to be able to infer admin status from a JWT, not assume admin status because we can parse the JWT. Here are a couple of ways we could accomplish this... thoughts?

1. Add an app header (i.e. x-app: Admin)
2. Add a standard JWT property (properties aud and sub could work for this purpose) https://en.wikipedia.org/wiki/JSON_Web_Token
3. Add registered JWT claim (amr, acr, and client_id could all be viable options)
4. Add a custom JWT claim (i.e. context: 'admin' | 'users-permissions')

I kind of favor number 4, but don't have a strong opinion.

Please let me know if you need help or feedback on any part of this process @derrickmehaffy. I'd be happy to donate a couple hours of company time to helping solve this issue if that would help.

[derrickmehaffy]

I figured out the root cause of this issue after about 3 days of debugging:

Check out this file: https://github.com/strapi/strapi/blob/86e0cf0f55d58e714a67cf4daee2e59e39974dd9/packages/strapi-admin/middlewares/auth/index.js

The above middleware runs on every request. It assumes because it can verify your JWT with the admin secret, that you should be an admin, looks up your admin user with your users-permissions_user id (super dangerous) and since it won't ever have the right role, fails.

The bottom line is if JWT_ADMIN_SECRET happens to equal JWT_SECRET, requests will fail...mostly. Requests will still succeed for users where there happens to be a strapi_administrator with the same id as their user-permissions_user.

In my opinion, this should be documented and then fixed. We need to be able to infer admin status from a JWT, not assume admin status because we can parse the JWT. Here are a couple of ways we could accomplish this... thoughts?

1. Add an app header (i.e. x-app: Admin)
2. Add a standard JWT property (properties aud and sub could work for this purpose) https://en.wikipedia.org/wiki/JSON_Web_Token
3. Add registered JWT claim (amr, acr, and client_id could all be viable options)
4. Add a custom JWT claim (i.e. context: 'admin' | 'users-permissions')

I kind of favor number 4, but don't have a strong opinion.

Please let me know if you need help or feedback on any part of this process @derrickmehaffy. I'd be happy to donate a couple hours of company time to helping solve this issue if that would help.

That would be a better question from @alexandrebodin on how best to handle it.