10.2. Request Source Authentication

10.2. Request Source Authentication

The source of the authorization request MUST always be verified. There are several ways to do it:

(a) Verifying the JWS Signature of the Request Object.

(b) Verifying that the symmetric key for the JWE encryption is the correct one if the JWE is using symmetric encryption. Note, however, that if public key encryption is used, no source authentication is enabled by the encryption, as any party can encrypt to the public key.

(c) Verifying the TLS Server Identity of the Request Object URI. In this case, the authorization server MUST know out-of-band that the client uses the Request Object URI and only the client is covered by the TLS certificate. In general, this is not a reliable method.

(d) When an authorization server implements a service that returns a Request Object URI in exchange for a Request Object, the authorization server MUST perform client authentication to accept the Request Object and bind the client identifier to the Request Object URI it is providing. It MUST validate the signature, per (a). Since the Request Object URI can be replayed, the lifetime of the Request Object URI MUST be short and preferably one-time use. The entropy of the Request Object URI MUST be sufficiently large. The adequate shortness of the validity and the entropy of the Request Object URI depends on the risk calculation based on the value of the resource being protected. A general guidance for the validity time would be less than a minute, and the Request Object URI is to include a cryptographic random value of 128 bits or more at the time of the writing of this specification.

(e) When a trusted third-party service returns a Request Object URI in exchange for a Request Object, it MUST validate the signature, per (a). In addition, the authorization server MUST be trusted by the third-party service and MUST know out-of-band that the client is also trusted by it.