Authn - Support RS256 and deprecate HMAC

[heilmela]

Summary

Allow directus to be integrated in environments where authentication and authorization is handled by third-party systems or different layers. The changes will make Directus more flexible and adaptable to diverse system architectures where auth/authz may be handled by other parties like proxies or microservices.

Basic Example

Introduce a config keys for JWT signing e.g.
AUTH_LOCAL_ALGORITHM = "HS256 | RS256...."

Use cisco/node-jose and add JWE as the default, with configurable RS256 JWTs in the local auth provider.

Motivation

We evaluate to run directus as part of a larger architecture and think about using directus as our primary identity provider. However there are concerns with the usage of HMAC and the inability to verify JWTs anywhere else than directus. (in our case we would like to verify the token at proxy level to provide authn to all upstream services).

The following points are addressed

• add the ability to configure the JWT algorithm and other options per config/env keys
• per default use JWE instead of HMAC signatures
• add a public JWKs endpoint

If you dont plan to support asymmetric keys i would still propose to deprecate the usage of HMAC since its exposes the JWT payload publicly. (for no particular reason i guess)

Detailed Design

Im adding some other requirements for our use case here which are potentially part of another RFC.
We would like to use directus as the self-designated BaaS but not as a single responsible monolith. Therefore we have permission policies and authentication at different layers. Right now we trick directus with extensions to not parse any token but take the identity out of the downstream. Some minor changes to directus would make this idea easier to implement:

• disable directus permissions via config
  this may be part of another RFC but would go hand in hand by letting third parties handle authz/authn
  From my perspective simply disabling the permission middleware and checks in the services would be enough

• allow external authn
  see above, key part of this RFC update the handling of JWTs

Requirements List

Must Have:

• jwks endpoint
• configurable signing

Should Have:

• disabled permission system

Drawbacks

implementation cost, both in term of code size and complexity

implementation could be minimal, complexity increases

whether the proposed feature can be implemented in user space

partially yes but right now there are no plugabble auth provider (?)

the impact on teaching people Directus

can be none to minimal - there are only a few optional api additions

cost of migrating existing Directus applications (is it a breaking change?)

no breaking change

Alternatives

Distributing shared HMAC key which not only imposes distributed key rotation problems, but is per design unnecessarily less secure

Adoption Strategy

These enhancements should not affect existing Directus installations. If system administrators do not change any configuration, Directus should function as it currently does, using its internal authentication and permissions system.

Unresolved Questions

No response

[rijkvanzanten]

Would you be able to walk me through your ideal setup on this sometime soon on discord? It sounds like you have a setup in mind, or have seen a setup somewhere that you have in mind that I'm missing the context on 🙂

[heilmela]

I have a packed schedule this week. I'll reach out to you on Discord when I'm available.

[cliqer]

WEAK JWT HASHING ALGORITHM

HS256 is a hashing algorithm commonly used in JSON Web Tokens (JWT). However, this uses a shared secret during the transformation of a plaintext message into a hash string/digest representing the information. Suppose the secret is sufficiently short in character length and weak in entropy (predictable words). In that case, it is possible to perform an automated secret-guessing attack ("brute-forcing" the hash) to discover the secret.
This would allow an attacker to edit the contents of the JWT, sign the message as if it were legitimate, and potentially escalate privileges if the contents of the JWT call for administrative resources.

Recommendation

Deprecate use of the HS256 algorithm and instead opt to use RS256 JWT Signature hashing.

References

https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/

[heilmela]

I'm not sure why this is labeled as a weak hashing algorithm when the comment describes a weak secret. Would you say a challenge-response process is flawed simply because one chooses a weak secret?

[heilmela]

@rijkvanzanten, is this still relevant? I haven't followed Directus's recent developments since my organization moved away from it, but I'm interested in using Directus for personal projects and might work on it in my spare time.

[rijkvanzanten]

I'm currently on the It's a nice to have, but haven't seen this come up enough to warrant going over to implementation in the current stack mindset here. I like the design and options it unlocks, but I can't prioritize it now as compared to the other more actively requested changes and features