A few comments and changes that I think should be made or would read more clearly.
3.1 Paragraph #2 Should probably read either of the following Clients SHOULD avoid forwarding the user's browser to a URI obtained from a query parameter since such a function could be utilized to exfiltrate authorization codes and access tokens. If there is a strong need for this kind of *redirect*, clients are advised to implement appropriate countermeasures against open redirection, e.g., as described by OWASP [owasp <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#ref-owasp>]. or Clients SHOULD avoid forwarding the user's browser to a URI obtained from a query parameter since such a function could be utilized to exfiltrate authorization codes and access tokens. If there is a strong need for *these* kind of redirects, clients are advised to implement appropriate countermeasures against open redirection, e.g., as described by OWASP [owasp <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#ref-owasp>]. 3.1.1 Last Paragraph Either should start with AS, like the others or server should be uppercase? Authorization servers SHOULD furthermore consider the recommendations given in [RFC6819], Section 4.4.1.1 <https://tools.ietf.org/html/rfc6819#section-4.4.1.1>, on authorization code replay prevention. 4.4.1, 4.5.2 The beginnings of each bullet list should be capitalized? (The) 4.8.1.3 Should maybe read An audience restriction essentially restricts access tokens to a particular resource server. The authorization server associates the access token with the particular resource server and thus a resource server SHOULD verify the intended audience. If the access token fails the intended audience validation, the resource server must refuse to serve the respective request. ..... The client SHOULD to tell the authorization server the intended resource server. The proposed mechanism [I-D.ietf-oauth-resource-indicators <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#ref-I-D.ietf-oauth-resource-indicators>] could be used or by encoding the information in the scope value. .... Audience restriction may seem easier to use since it does not require any crypto on the client-side. Still, since every access token is bound to a specific resource server, the client also needs to obtain a single RS-specific access token when accessing several resource servers. [I-D.ietf-oauth-token-binding] has the same property since different token binding ids must be associated with the access token. Using [I-D.ietf-oauth-mtls], on the other hand, allows a client to use the access token at multiple resource servers. 4.8.2 I think would read better with the following An attacker may compromise a resource server to gain access and to other resources of the respective deployment. Such a compromise may range from partial access to the system, e.g., its log files, to full control of the respective server. If the attacker were able to gain full control, including shell access, it would be able to circumvent all controls and access resources. It would also obtain other access tokens held on the compromised system, which would potentially be valid to access other resource servers. Preventing server breaches by hardening and monitoring server systems is considered a standard operational procedure and, therefore, out of the scope of this document. This section focuses on the impact of such OAuth-related breaches and the replaying of captured access tokens. 4.9.1 Attackers could try to utilize a user’s trust in the authorization server (and its URL in particular) for performing phishing attacks. [RFC6749], Section 4.1.2.1, already prevents open redirects by stating the AS MUST NOT automatically redirect the user agent in case of an invalid combination of client_id and redirect_uri. However, as described in [I-D.ietf-oauth-closing-redirectors], an attacker could also utilize a correctly registered redirect URI to perform phishing attacks. It could, for example, register a client via dynamic client registration [RFC7591] and intentionally send an erroneous authorization request, e.g., by using an invalid scope value, thus redirecting instructing the AS to redirect the client to the desired phishing site. The AS MUST take precautions to prevent this threat. Based on its risk assessment, the AS needs to decide whether it can trust the redirect URI and SHOULD only automatically redirect the user agent if it trusts the redirect URI. If the URI is not trusted, it MAY inform the user and rely on the user to make the correct decision. 4.9.2 Clients MUST NOT expose URLs, which could be utilized as an open redirector. Attackers may use an open redirector to produce URLs that appear to point to the client, which might trick users into trusting the URL and following it in their browser. Another abuse case is to produce URLs pointing to the client and utilize them to impersonate a client with an authorization server. The client should only expose a URL, if the target URL(s) is whitelisted or if the origin of the request can be confirmed. 4.11 (last paragraph) If an attacker was able to get access to the internal network between proxy and application server, the attacker could also try to circumvent security controls in place. It is, therefore, essential to ensure the authenticity of the communicating entities. Furthermore, the communication link between reverse proxy and application server must be protected against eavesdropping, injection, and replay of messages. P.S. I am out for the next 8 days and will not be able to respond to any comments or questions until after the 15th. -Jared Skype:jaredljennings Signal:+1 816.730.9540 WhatsApp: +1 816.678.4152
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
