To create redirect_uri in OAuth2AuthorizationRequestRedirectWebFilter,
queryParam is included in the current request-based baseUrl.
So when binding to the redirectUriTemplate,
the wrong type of redirect_uri may be created.
Fixed: gh-5520
This section defines three methods of sending bearer access tokens
in resource requests to resource servers.
Clients MUST NOT use more than
one method to transmit the token in each request.
RFC6750 Section 2 Authenticated Requests
https://tools.ietf.org/html/rfc6750#section-2
Add AuthenticationMethod in ClientRegistration UserInfoEndpoint.
Add AuthenticationMethod for OAuth2UserService to get User.
To support the use of the POST method.
https://tools.ietf.org/html/rfc6750#section-2.2
gh-5500
Allows scope of OAuth2 ClientRegistration to be null.
- The scope setting in the RFC document is defined as Optional.
https://tools.ietf.org/html/rfc6749#section-4.1.1
> scope: OPTIONAL.
> The scope of the access request as described by Section 3.3.
- When the client omits the scope parameter,
validation is determined by the authorization server.
https://tools.ietf.org/html/rfc6749#section-3.3
> If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).
Fixes gh-5494
To create redirect_uri in DefaultOAuth2AuthorizationRequestResolver,
queryParam is included in the current request-based baseUrl.
So when binding to the redirectUriTemplate,
the wrong type of redirect_uri may be created.
Fixes gh-5520
A test against the Nimbus library was relying on specific messaging
from Nimbus as well as the JDK, making it brittle.
Now, it simply relies on the messaging that we control.
Issue: gh-4887
It is quite likely we will need to prevent certain Exceptions from being
saved or from triggering a saved request. When we add support for this,
we can now leverage @Transient vs creating a new annotation.
Issue: gh-5481
Introducing initial support for Jwt-Encoded Bearer Token authorization
with remote JWK set signature verification.
High-level features include:
- Accepting bearer tokens as headers and form or query parameters
- Verifying signatures from a remote Jwk set
And:
- A DSL for easy configuration
- A sample to demonstrate usage
Fixes: gh-5128
Fixes: gh-5125
Fixes: gh-5121
Fixes: gh-5130
Fixes: gh-5226
Fixes: gh-5237
When Nimbus fails to parse either a JWK response or a JWT response,
the error message contains information that either should or cannot be
included in a Bearer Token response.
For example, if the response from a JWK endpoint is invalid JSON, then
Nimbus will send the entire response from the authentication server in
the resulting exception message.
This commit captures these exceptions and removes the parsing detail,
replacing it with more generic information about the nature of the
error.
Fixes: gh-5517
Change the TokenType to Serializable
so that the OAuth2AccessToken can be serialized.
(org.springframework.security.oauth2.core.OAuth2AccessToken.TokenType)
Fixes gh-5492
This commit captures and remaps the exception that Nimbus throws
when a PlainJWT is presented to it.
While the surrounding classes are likely only used today by the
oauth2Login flow, since they are public, we'll patch them at this
point for anyone who may be using them directly.
Fixes: gh-5457
Joe Grandja
Johnny Lim
mhyeon.lee
Rob Winch
Josh Cummings