Support for additional JWT signing algorithms

[rokf]

Hello,

I've noticed that the ParseJWT function (called parseJWT in the JS VM) only supports the HS256 algorithm - https://github.com/pocketbase/pocketbase/blob/master/tools/security/jwt.go#L28.

Have you perhaps ever considered extending that to some additional (asymmetric) algorithms?

The idea here is that one could use the ParseJWT function to validate JWTs that came from the outside world and weren't produced by PocketBase, which signs them with HS256.

Example: Let's say that I want to accept and validate tokens produced through the client credentials flow (grant) with something like Pocket ID, which doesn't (yet) support HS256 for signing tokens - https://pocket-id.org/docs/advanced/custom-keys.

Note

I'll ask them (Pocket ID maintainers) as well if they're willing to include HS256 in the list of supported token signing algorithms.

Thank you!

[ganigeorgiev]

This was suggested in the past in various forms (#5227, #3933, #2997, etc.) but there are no plans to change the tokens signing for now.

I'm not entirely sure that I understand how do you plan to integrate with Pocket ID but please keep in mind that PocketBase JWTs are a little bit unorthodox because each user has a unique secret. Which usually would mean that it is not really feasible to validate a PocketBase token from an external application without sending a request because you'll have to somehow get access to the database to extract the user's specific tokenKey + the collection base secret for the token type in order to construct the full verification key.

Side-note: if you are using Go and want to validate custom tokens, you don't have to use the ParseJWT helper and can instead directly invoke the underlying github.com/golang-jwt/jwt/v5 library.

[ganigeorgiev]

To help with custom pb_hooks integrations (if that's actually the main issue?) I've added a task in the roadmap to consider exposing additional helpers to the JSVM since I plan to do some minor refactoring on the security package anyway but there are no ETAs (PocketBase issued tokens remains HMAC based for now).

[rokf]

The flow I had in mind goes the other way around 😄

I'd like to validate M2M JWT tokens that were issued by Pocket ID in custom routes that I've added to PocketBase through the JS VM. I'd parse the JWT out of the authorization header, fetch the signing keys from Pocket ID with $http.send, and validate it with $security.parseJWT, etc.

I suppose that I could achieve the same (or similar) thing by creating a "dummy" auth collection in PocketBase, enabling OAuth2 on it with a custom OIDC IdP integration, and then relying on PocketBase's internal OIDC validator and middleware to do the token validation in my custom routes - it doesn't seem to have the HS256 limitation. The collection would be empty and would only be there to handle the validation of JWTs for incoming requests 🤔 I'd be limited to 3 custom OAuth 2.0 providers per auth collection this way though if I understand PocketBase's OAuth2.0 configuration UI correctly.

The tokens in my case wouldn't be tied to human users - they'd essentially be produced through the client credentials grant with OIDC clients (stored in Pocket ID, or any other IdP for that matter) acting as M2M API users 🙂

[ganigeorgiev]

Thank you for elaborating, I think I understand now. As mentioned above I'll consider exposing additional security helpers to the JSVM but there are no ETAs, so if you really want to parse custom JWTs you may have to switch to Go.

A slightly hacky workaround, depending on the token permissions/scopes, could be to send a direct Pocket ID request to endpoints like "Get current user" or maybe better "Get user information", which I assume will do the token verification on the server side for you.

Regarding the dummy auth collection option - that's technically also could be an alternative but I'm not sure how would you execute it for server-to-server flows, especially from the JSVM, since we currently don't expose much of the OAuth2 implementation. And Yes, out of the box there are only 3 OIDC providers allowed but you can extend it with Go and register as many as you want (there is an example in #7748).