OAuth, Add Requirement about exposing data through authorization_details

[randomstuff]

In OAuth RAR, the authorization_details in the authorization request can contain a lot of data. Should we add a requirement that sensitive information should not be exposed to the user this way?

See the related privacy considerations section:

Any sensitive personal data included in authorization_details must be prevented from leaking, e.g., through referrer headers. Implementation options include encrypted request objects as defined in [RFC9101] or transmission of authorization_details via end-to-end encrypted connections between client and AS by utilizing [RFC9126] and the request_uri authorization request parameter as defined in [RFC9101]. The latter does not require application-level encryption, but it requires another message exchange between the client and the AS.

PAR or JAR can be used if this is a problem.

Straw man wording:

Verify that the user cannot see confidential data in RAR requests. This can be achieved with PAR or JAR (JWE+JWS).

Argument against: This requirement can be generalized to other requests (outside of OAuth) which is one reason for not including this requirement in the OAuth chapter. This is somewhat related to 8.1.10.

Note: the authorization_details in the token response could contain sensitive information as well but usually won't be accessible to the end-user when using a server-side confidential client with the authorization code flow.

Context: #2036

Related to: #2151

[elarlang]

Haha, I checked the RFC and commented on that to previous issue: #2151 (comment)

I have tried to address this problem via:

• V.8.1 Verify that all sensitive data created and processed by the application has been identified and classified into protection levels, and ensure that a policy is in place on how to deal with sensitive data. Note that this includes sensitive data that is being encoded in a recoverable form such as Base64 and JWT.
• V8.3.1 Verify that sensitive data is only sent to the server in the HTTP message body or headers and that the URL and query string do not contain sensitive information, such as an API key or session token.

[randomstuff]

Yes, these requirements should be enough and there is probably no need to add the case covered by authorization_details.

But when watching the RFC9396, it seems like another "approved by RFC" way to leak sensitive information (the content of authorization_details) via URL parameters.

Yes. I was going to say that you can use PAR or JAR to protect against this but that's not actually completely true. An attacker which would be able to intercept the authorization request from the URL parameters might possibly be able to see some authorization details from the authorization server's consent screen.

[elarlang]

By principle we have it (session data leakage) covered.

To have a special case for "if rar is used + if the public client is used + if sensitive data is used" feels a bit too edge case and out of line compared to other requirements in the ASVS and feels more like a checklist-style testing guide area.

So the current proposal is - we know this edge case exists, by principle it is covered and we don't add a new separate requirement.