Security consideration: add warning about creating phishing links

[aaronpk]

Under certain circumstances, PAR could be used to create phishing links at the authorization server's domain. This should be listed as a security consideration, along with the circumstances under which this can happen and how to avoid it.

Specifically, if a public OAuth API (e.g. github, google, twitter) uses PAR, then a malicious developer could register a client with a redirect URI of the attacker's website, then create a PAR request that will redirect to that URI (either with a valid authorization code if the user approves the request, or with an error code if the user denies or if there is some other problem). This also applies to authorization servers supporting unauthenticated dynamic client registration.

The difference between this and the traditional OAuth model is that the malicious redirect would be not visible until after the redirect has happened, whereas in traditional OAuth it would be in the actual authorization URL itself as the redirect_uri parameter. Essentially PAR lets an attacker mask the redirect URI under the opaque request_uri.

There is no mitigation for these situations, so they should be called out so developers are aware of the risk. To avoid the potential for these attacks, the authorization server would need to prevent arbitrary client registration or have a manual approval process.

[tlodderstedt]

I agree, PAR can be used to produce short URLs on the AS's domain. However, your proposal would effectively limit use of PAR to vetted, confidential clients. Do you think this is appropriate/needed?

I think the recommendation given in the Security BCP (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-18#section-4.10.2) is still applicable.

[aaronpk]

I'm not suggesting limiting any functionality, just pointing out the situation when used without client authentication under security considerations.

[tlodderstedt]

Understood. Would you expect any recommendation beyond https://tools.ietf.org/html/draft-ietf-oauth-security-topics-18#section-4.10.2?