You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the OP fails to establish trust with the RP, it SHOULD use an appropriate error code and an error_description that aids the RP in understanding what is wrong.
In addition to the error codes contained in the IANA "OAuth Extensions Error Registry" registry [IANA.OAuth.Parameters], this specification also defines the following error codes:
The description seems a bit vague and things seem to be implied. Only in the example we can see that this is actually a redirect response (and we can only guess that it is a RP redirect_uri). Is this supposed to be returned as per OAuth2 spec to the redirect_uri supplied in authorization request? If so, OAuth2 has some restrictions on when the redirect_uri can be used to return error with redirect and when we should only "inform" about error: (https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1.2.1):
If the request fails due to a missing, invalid, or mismatching
redirection URI, or if the client identifier is missing or invalid,
the authorization server SHOULD inform the resource owner of the
error and MUST NOT automatically redirect the user-agent to the
invalid redirection URI.
If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client by adding the following
parameters to the query component of the redirection URI using the
"application/x-www-form-urlencoded" format, per Appendix B:
If the End-User denies the request or the End-User authentication fails, the OP (Authorization Server) informs the RP (Client) by using the Error Response parameters defined in Section 4.1.2.1 of OAuth 2.0 [RFC6749]. (HTTP errors unrelated to RFC 6749 are returned to the User Agent using the appropriate HTTP status code.)
Unless the Redirection URI is invalid, the Authorization Server returns the Client to the Redirection URI specified in the Authorization Request with the appropriate error and state parameters. Other parameters SHOULD NOT be returned. If the Redirection URI is invalid, the Authorization Server MUST NOT redirect the User Agent to the invalid Redirection URI.
In case of OAuth2 / OIDC it is implied that the client is already registered so we can check if the redirect_uri is valid. This brings me to the question - for example, in case of OpenID Federation Automatic Registration error, and the reason for error being trust chain validation failure, we won't have resolved RP metadata at all. Is it ok, in that case, to trust redirect_uri parameter supplied in authorization request and return the error to it?
Either way, I suggest being a bit more clearer in the description about error response, for example there is no mention that the error should be returned to RP redirect_uri or similar.
The text was updated successfully, but these errors were encountered:
As cited from RFC 6749, the authorisation endpoint of an AS / OP must not act on the redirect_uri when:
The client_id is invalid, i.e. the AS / OP doesn't recognise the client / RP
The client is recognised but the redirect_uri has not been registered for it
When we take these two rules and apply them to Federation, it follows that authorisation requests from a party that is not trusted must be rejected. Since the party is not trusted, the supplied redirect_uri must not be used either, meaning there is no automatic redirect from the OP to the redirect_uri with an error code.
The two Federation specific error codes defined for automatic registration error responses - missing_trust_anchor and validation_failed will get transmitted back to the caller only when we have PAR, i.e. a backchannel request to the OP. For a regular (front-channel) authentication request you may display them to the user (this is what we chose to do in the c2id implementation).
My proposal is to update the spec text along these lines, i.e. that the redirect_uri of a party that isn't trusted must not be used.
The naming of the validation_failed error could also be improved. We already have a bunch of OAuth and OIDC error codes and it would help to have a name that makes the Federation relation clear. With a code like trust_chain_validation_failed for instance.
This commit says that redirection should not be performed when trust cannot be established. It also says that the new error codes can be used with PAR.
In OpenID Federation regarding 12.1.2. Authentication Error Response it is stated:
The description seems a bit vague and things seem to be implied. Only in the example we can see that this is actually a redirect response (and we can only guess that it is a RP
redirect_uri
). Is this supposed to be returned as per OAuth2 spec to the redirect_uri supplied in authorization request? If so, OAuth2 has some restrictions on when the redirect_uri can be used to return error with redirect and when we should only "inform" about error: (https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1.2.1):Similarly, in OpenID Core:
In case of OAuth2 / OIDC it is implied that the client is already registered so we can check if the
redirect_uri
is valid. This brings me to the question - for example, in case of OpenID Federation Automatic Registration error, and the reason for error being trust chain validation failure, we won't have resolved RP metadata at all. Is it ok, in that case, to trustredirect_uri
parameter supplied in authorization request and return the error to it?Either way, I suggest being a bit more clearer in the description about error response, for example there is no mention that the error should be returned to RP
redirect_uri
or similar.The text was updated successfully, but these errors were encountered: