Support for OIDC message-level encryption

ORY Hydra
#1

The company I work for is considering is considering ORY Hydra to replace our current OIDC/OAuth2 server. However, one of the IDPs we must support has very strict requirements for full message-level encryption, as well as transport-level encryption. This demand does not only apply to communication between us (identity broker) and their IDP, but it extends to the communication between the end-user and us.

With our current server we are able to implement this in a manner which we are confident fulfils the demands of the IDP: (since I can’t post links I will refer to sections from https://openid.net/specs/openid-connect-core-1_0.html)

    1. Passing Request Parameters as JWTs - " to enable Authentication Requests to be signed and optionally encrypted"
    1. ID Token - " ID Tokens MUST be signed using JWS and optionally both signed and then encrypted using JWS and JWE respectively"
  • 5.3.2. Successful UserInfo Response - “The UserInfo Claims MUST be returned as the members of a JSON object unless a signed or encrypted response was requested during Client Registration”

Our current implementation allows us to enforce these settings on a per-client basis.

Does ORY Hydra currently support these parts of the OIDC core specs? In fact, does ORY Hydra have full coverage of the OIDC core specs?

PS: The reasons we are changing OIDC server is not directly related to this issue, but any new OIDC/OAuth2 implementation needs to have full feature coverage of our current implementation.

#2

Thank you for your question. Hydra currently relies on TLS as a method to encrypt messages in transport. Encrypting JWT Auth Requests, ID Tokens, and UserInfo responses is primarily used in scenarios where TLS is not suitable, which is forbidden per policy in Hydra.

However, it would be possible to add those features. We have however iceboxed new feature requests for Hydra as we’re working on other projects in the stack.

If you want this feature to land:

  1. Consider opening a discussion on GitHub to prepare a contribution (PR) with these features. Be aware that this will not be done in a day or two.
  2. Consider sponsoring (open collective, patreon) our work so we can hire more people to work on things like these.

Best

#3

Thanks for the answer.

I’ve looked a bit at the Fosite source code, and it appears to support signed request objects but not encrypted is this correct? Re https://github.com/ory/fosite/blob/master/authorize_request_handler.go#L38-L158

#4

Sorry, just catching up with everything after vacation - yes that is correct!