BearerTokenError validates its constructor parameters against the character set specified by RFC 6750. For example:
Assert.isTrue(isScopeValid(scope),
"scope contains invalid ASCII characters, it must conform to RFC 6750");
This is becauseBearerTokenError is a class that intentionally represents OAuth 2.0 bearer token errors from RFC 6750.
We ought to consider having OAuth2Error validate its constructor parameters against the character set specified by RFC 6749.
OAuth2Error appears to be a class that intentionally represents OAuth 2.0 errors from RFC 6749.
Not verifying that errorCode, description, and errorUri meet this criteria may be a bug. Reports in other libraries demonstrate where allowing invalid characters can cause problems.
Comment From: barclay-reg
seems like this is fixing https://github.com/spring-projects/spring-security-oauth/issues/997 and https://github.com/spring-projects/spring-security-oauth/issues/889 finaly, correct?
Comment From: jzheaux
@barclay-reg thanks for checking in, however, those tickets are to a separate plugin project. This ticket is referring to Spring Security's built-in support for OAuth 2.0.
Comment From: jgrandja
@jzheaux I don't think we should validate OAuth2Error.description. See comment
Comment From: rwinch
It seems that it might make more sense when we render vs in the Exception itself. Checking in the Exception is a bit like HTML escaping in an Exception just in case it is rendered as an HTML response.