2

I'm working on a provider where it is required by external factors that the id token and the userinfo always be encrypted. The server itself is and must be zero-knowledge (as weird as it sounds).

In my understanding the core spec does not forbid this. Dynamic client registration is also supported but all id_token_encrypted*/userinfo_encrypted* client metadata parameters are overridden by the server if they were not provided. According to the spec the server is allowed to do this.

The discovery spec however doesn't seem to support the idea since there is no way to tell the client that unencrypted responses will not be returned.

The conformance testing tool also seems to assume the response is unencrypted. In order to be able to run the tests I had to make an exception for this specific client. Now I only return signed responses, but even if this passes, it's not the real thing.

Does this prevent me from getting verified or I may pass verification using this slightly modified server while requiring real clients to support encryption?

geri
  • 58
  • 7
Ercinee
  • 23
  • 7

3 Answers3

1

One cannot certify without supporting unencrypted RSA SHA-256 signed ID tokens. However, you can certify a software implementation and then disable particular algorithms at deployment time.

edit: the only exception to this is supporting "none" but that is not relevant for your case

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • Thank you for confirming this :) – Kavindu Dodanduwa Aug 07 '18 at 11:14
  • My only problem with this is that I don't really see a way to state in metadata that the responses will always be encrypted. I would need to disable the lack of any algorithms. "none" is a signature algorithm but there's no such thing when it comes to JWE (or I missed something). Even if there was, I think what ..._encryption_alg_values_supported metadata fields mean is what other encryption is supported **besides** no encryption. I'd like to avoid confusing clients who might assume the ID token is only signed, even if I'm technically right when I'm overriding their registration metadata. – Ercinee Aug 07 '18 at 11:50
  • you can indicate which encryption you're supporting using the `encryption_alg_values_supported` field and then just start returning encrypted id_tokens – Hans Z. Aug 07 '18 at 19:19
0

I think you must support singed ID Tokens. This is mandatory by OpenID Connect specification.

15.1. Mandatory to Implement Features for All OpenID Providers

Signing ID Tokens with RSA SHA-256

OPs MUST support signing ID Tokens with the RSA SHA-256 algorithm (an alg value of RS256), unless the OP only supports returning ID Tokens from the Token Endpoint (as is the case for the Authorization Code Flow) and only allows Clients to register specifying none as the requested ID Token signing algorithm.

This is highlighted in ID Token section too

ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively

Further it says about none type which is only

ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.

Encrpyted JWT (JWE) is optional. So to get your OpenID Connect provider certified, you must support signing.

Furthermore, read through OpenID Connect Conformance Profiles v3.0 which serves as the guideline for certification.

Kavindu Dodanduwa
  • 12,193
  • 3
  • 33
  • 46
  • Thank you for your response but it seems you misunderstood the problem. The returned answers are always signed (we don't even support the signing alg 'none'). But we don't (and can't) return unencrypted responses. In short we always return responses signed AND encrypted. [OpenID Connect Dynamic Client Registration](https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse) says that "The Authorization Server MAY reject or replace any ... field values and substitute them with suitable values. ... An Authorization Server MAY ignore values provided by the client... " – Ercinee Aug 07 '18 at 11:25
  • @Ercinee Well I think my answer is not well formatted. What I wanted to highlight was mandatory signing requirement. Encryption is optional and same for none. So to get certified you must use signing. Hope it's clear now – Kavindu Dodanduwa Aug 07 '18 at 11:35
0

The discovery spec however doesn't seem to support the idea since there is no way to tell the client that unencrypted responses will not be returned.

While the discovery does not have a way communicating this the Dynamic Registration specification allows the IdP to do so.

Returning userinfo_encrypted_response_alg and userinfo_signed_response_alg with your pre-defined values to a client registration request is a way of saying that's what the IdP policy is.

The relevant part:

The Authorization Server MAY reject or replace any of the Client's requested field values and substitute them with suitable values.