Fix for using opaque tokens without a warning

[matt-humaan]

We have a system that doesn't benefit from the overhead of managing public and private keys. We want to use opaque tokens in production. At present if you don't configure a JWKS then a warning is logged.

We attempted to remove this warning by supplying an empty JWKS. With no asymmetric keys in use, we don't need any entries in the JWKS. However when doing this we get the error:

{"error":"invalid_client_metadata","error_description":"id_token_signed_response_alg must not be provided (no values are allowed)"}

This branch has a change that fixes this by allowing the 'none' algorithm to be used, without advertising it during connection handshakes.

matt-humaan#1

Am I misinformed? Are opaque tokens really not a good idea?

Assuming they are a legitimate approach, can I be added as a collaborator in order to create the PR?

[panva]

Providing an empty JWKS is valid, but it also means the AS has no asymmetric key material, so no asymmetric signing algorithms are effectively supported by the provider metadata.

The confusing part is that some client metadata defaults are still RS256 (for example id_token_signed_response_alg), so if you leave those defaults in place while the provider supports no signing algs there, validation fails with “must not be provided (no values are allowed)”. Which also means you've also disabled the symmetric HMAC based algorithms? I guess so.

I will not be adding alg=none support back. I've happily removed it in 8.0.0.

Yes it's a bit awkward if all you want to support is the client_credentials grant but honestly just add the AS JWKS.

Also please keep in mind the purpose of this Discussion category.

Ideas
Share ideas for new features such as configuration options, extension points, or updates to existing ones. Entries here are not meant for Q&A. Only fully-fledged ideas with description, examples and clearly stated "why" or "what for" stand a chance of being discussed, otherwise they will be closed and eventually removed.

[matt-humaan]

which category would have been better? for future reference

[matt-humaan]

Thank you for your swift answer. We will just supply a dummy key in the set