Response type parameter handling in authorization endpoint
Basics
Logistics
Basics
Logistics
Description
So far we’ve followed OAuth2 core RFC [1] and OIDC core [2] regarding the handling of response_type parameter. They’re compatible with each other as the RFC section 3.1.1 says:
And OIDC core’s section about request object (6.1.):
So that the request is a valid OAuth 2.0 Authorization Request, values for the response_type and client_id parameters MUST be included using the OAuth 2.0 request syntax, since they are REQUIRED by OAuth 2.0. The values for these parameters MUST match those in the Request Object, if present.
However, I was wondering why all the examples to authorization endpoint in the OAuth2 PAR RFC [3] are not containing response_type parameter. Even if it’s included in the request object created via PAR, the two specs above still clearly requires the use of it.
The reason might be the OAuth2 JAR RFC [4], which defines the “generic” request object contents. It’s dated after the OIDC core, that probably was the first spec that specified the use of request object, but obviously within the OIDC context. The section 6.3 describes how the request parameters should be assembled and validated:
The authorization server MUST extract the set of authorization request parameters from the Request Object value. The authorization server MUST only use the parameters in the Request Object, even if the same parameter is provided in the query parameter. The client ID values in the client_id request parameter and in the Request Object client_id claim MUST be identical.
It’s not directly saying that the response_type parameter requirement from the OAuth2 RFC doesn’t need to be fulfilled, but clearly says that it should be ignored as only the values from request objects should be used.
I also noticed that Nimbus AuthorizationRequest object parser doesn’t require response type parameter when the request object is used. The code actually even contains the following comment:
Mandatory response_type, unless in JAR
I probably need to do some more studying to find references about how we should deal with the parameter. Perhaps it’s already mentioned in the specs I referenced, but I just didn’t spot it.
So far we’ve followed OAuth2 core RFC [1] and OIDC core [2] regarding the handling of response_type parameter. They’re compatible with each other as the RFC section 3.1.1 says:
And OIDC core’s section about request object (6.1.):
However, I was wondering why all the examples to authorization endpoint in the OAuth2 PAR RFC [3] are not containing response_type parameter. Even if it’s included in the request object created via PAR, the two specs above still clearly requires the use of it.
The reason might be the OAuth2 JAR RFC [4], which defines the “generic” request object contents. It’s dated after the OIDC core, that probably was the first spec that specified the use of request object, but obviously within the OIDC context. The section 6.3 describes how the request parameters should be assembled and validated:
It’s not directly saying that the response_type parameter requirement from the OAuth2 RFC doesn’t need to be fulfilled, but clearly says that it should be ignored as only the values from request objects should be used.
I also noticed that Nimbus AuthorizationRequest object parser doesn’t require response type parameter when the request object is used. The code actually even contains the following comment:
Mandatory response_type, unless in JARI probably need to do some more studying to find references about how we should deal with the parameter. Perhaps it’s already mentioned in the specs I referenced, but I just didn’t spot it.
[1]
[2]
[3]
[4]