Improve SSRF security considerations

[ThisIsMissEm]

This applies #43

Essentially there are two attack vectors:

1. When fetching the Client ID Metadata Document itself, that must not resolve to a special-use IP address, except if the Authorization Server is running on the same IP address (this is to enable development of the AS & Client on the same machine)
2. When fetching any of the URLs contained within the Client ID Metadata Document, such as tos_uri, policy_uri, jwks_uri or logo_uri

We may need an exception for jwks_uri like we have for the Client ID Metadata Document URI itself.

[ThisIsMissEm]

We may want to go further here, like Bluesky's AT Proto, by verifying that the hostname has at least two components, and prevents usage of the following TLDs:

• .test
• .local
• .localhost
• .invalid
• .example

However, these TLDs may be useful when developing locally the AS and Client.

[OR13]

Suggested change

Authorization servers SHOULD avoid fetching any URLs contained within Client ID Metadata Documents that resolve to special-use IP addresses as defined in [RFC6890] and consider network policies or other measures to prevent making requests to these addresses. Authorization servers SHOULD also be aware of the possibility that URLs might be non-http-based URI schemes which can lead to other possible SSRF attack vectors.

Authorization servers SHOULD NOT fetch any URLs contained within Client ID Metadata Documents that resolve to special-use IP addresses as defined in [RFC6890] and consider network policies or other measures to prevent making requests to these addresses. Authorization servers which support non-http-based URI schemes are at additional risk to SSRF attacks.

[ThisIsMissEm]

@aaronpk how's this sound to you?