spring-projects / spring-authorization-server Goto Github PK

Hi thanks for the newly rewritten spring security & spring auth server! I wonder when will it be stable to be used in commercial production environment?

In other words, if I need to use an OAuth solution in about 3 months (say, July), then which do you suggest:

1. The deprecated Spring Security Oauth
2. The new Spring Security, with 3rd party like Keycloak
3. The new Spring Security, with this repo (stable?)

Thanks very much!

This will deliver the Refresh Token Grant.

We need to setup GitHub issue / pull request templates.

We can leverage the existing Spring Security templates as a base and modify if necessary.

It would also be very convenient to configure a template chooser so a user can select the type of issue being logged. See the Gradle "New Issue Chooser" as an example.

• Configuring issue templates
• Configuring the template chooser

Hi Everyone!

I understand that a big chunk of the Java community is still stuck on Java 8, but I wonder if there are any other reason why this project should still have compatibility to that version. As I understand it is not a supported version anymore and Java 11, the current LTS version has already been around for almost 2 years now. Wouldn't it be a good idea to default to Java 11 for this project?

This issue will deliver OpenID Connect 1.0 Authorization Code Flow.

An authorization server needs to maintain existing authorizations between a client and resource owner. For example, when a resource owner grants access to a client (to access its protected resources), the authorization server must persist certain data in order to validate the authorization grant flow until it completes.

For example, during an authorization_code grant flow, the authorization server must persist the following data:

• Certain Authorization Request parameters - OAuth2AuthorizationRequest
• The identifier of the client - client_id
• The identifier of the resource owner - current Authentication.getName()
• The authorization code parameter
• The granted access token - OAuth2AccessToken

The initial implementation should provide an in-memory implementation of OAuth2AuthorizationService, similar to InMemoryOAuth2AuthorizedClientService in the spring-security-oauth2-client module.

Implementation Requirements

• InMemoryOAuth2AuthorizationService should store in a Map
• OAuth2Authorization should be immutable
• OAuth2Authorization.attributes should be used for storing data that is specific to an authorization grant, eg. authorization code parameter, OAuth2AuthorizationRequest, etc.
• javadoc class and public methods
• Unit tests

Specification References

4.1. Authorization Code Grant

We should align the GitHub labels the same as the Spring Security labels.

Here is a list of the currently published IETF OAuth 2.0 standards and their status:

This epic should group all issues that will deliver support for Device Authorization Grant as per RFC8628.

An authorization server should support a /authorize endpoint.

The endpoint should support the authorization code grant. It should verify the response_type, client_id, redirect_uri, scope, and state parameters and formulate an authorization response. The redirect_uri, scope, and state parameters are optional but MUST be verified if present.

The authorization code response should consist of code and state parameters. The state parameter is optional but MUST be returned if provided in the authorization request.

This task will add Spring Security and ensure that all of the additional Filter's (gh-3, gh-5) are added to Spring Security in the proper places. We should start by using the existing Spring Security DSL (no need to create a custom DSL at this point).

We should review CONTRIBUTING and ensure the content is relevant for this project.

This epic will track the progress of the following feature:

Provide an implementation of the Authorization Request/Response (Exchange) for the authorization_code grant.

This epic is divided into multiple issues, in order to support parallel work streams.

#66 Implement Authorization Endpoint

See the ZenHub project board.

This epic groups the issues/tasks we should strive to complete before we publish the blog post.

This epic will deliver OAuth 2.0 Token Revocation.

This sample should integrate with spring-security-oauth2-client and spring-security-oauth2-resource-server.

Add support for Client Credentials Grant.

This epic groups all the issues that will deliver a Spring Boot sample realizing the client_credentials grant flow.

Please review the Client Credentials Grant to gain an understanding of the flow.

This epic will track the progress of the following feature:

Provide an implementation of the Access Token Request/Response (Exchange) for the authorization_code grant.

This epic is divided into multiple issues, in order to support parallel work streams.

#39 Implement Client Authentication
#67 Implement Token Endpoint
#68 Implement authorization_code AuthenticationProvider

See the ZenHub project board.

This feature will deliver OAuth 2.0 Device Authorization Grant.

Related to Spring Security client support

Hello there!

Where I work at our UAA must handle different ways of authentication. For example, with the grant Resource Owner Password Credentials our UAA offers 3 ways of authentication:

• Default:
  • e-mail
  • password
• Credentials:
  • user's social number, company registration number, etc
  • password
• Delegation:
  • target a custom microservice to authenticate the user

For the grant Client Credentials it offer 2 ways:

• Default backend client credentials
  • Authentication used between our microservices to call each other.
• External client credentials
  • Third party application that communicate with our endpoints.

Using the legacy authorization server it was not nice to achieve this behavior. For example, the default email+password was a first class citizen, while other handlers had to "try hard" to be put to work.

Since the announcement of the authorization server discontinuation I wrote a new UAA for our company, and since I knew that there would be N ways of handling a specific grant type, I designed the application in order to facilitate the handler implementations.

But, now that Spring will create a new authorization server, I will try to use it instead of our own, even tho our own works perfectly fine. I just don't like reinventing the wheel.

Finally, my request is (and I guess this would already be on yours todo list) to abstract the authentication handlers so it would be easy to enhance the authorization server with N ways of authenticating a user (following the OAuth2 framework, of course). There should not be a first class citizen (looking at you UserDetailsService), but instead it should offer a nice abstraction for us to add the required ways of authentication.

This is just to clarify the idea, and by all means not how you should do it, but this is what we did in our UAA: The handlers must have some kind of way to answer the question: "should I handle this authentication request?". In order to answer that our handler interface has 2 methods:

• Boolean canHandleGrantType(GrantType grantType)
• Boolean canHandleAuthentication(TokenRequest tokenRequest, HttpServletRequest request)

The first one is the cheaper one. It will answer if it can (so far) handle the authentication grant type. For example, the DelegationAuthenticationHandler can handle GrantType.PASSWORD. So if the request is to authenticate client credentials, this handler would be skipped.

The second one will answer if it will handle that authentication based on those two parameters. For example, the DefaultAuthenticationHandler will handle it if the tokenRequest (which has the username) contains an username with @ and the http request doesn't have a delegation header.

And what about if 2 handlers can handle the same request? We defined that if the handler returns null it means "I didn't find the user, but other handler can try it". This will not stop the authentication process to try another available handler. If the handler throws a specific exception, this means that the authentication has failed and no more handlers should be tried.

From the example above we have 2 handlers. Which one should handle first? We control that with a simple @Order on our handlers.

Again, all this above is just to clarify the idea and the need for multiple handlers for every grant type.

Best regards.

The client must authenticate when calling the authorization server's token endpoint.

The OAuth2ClientAuthenticationFilter should be implemented as a Filter. The initial implementation should support HTTP Basic only.

Implementation Requirements

• the Filter should process requests for the (default) path /oauth2/token and if HTTP Basic credentials are available in the request
• the OAuth2ClientAuthenticationToken should be passed to the AuthenticationManager
• the AuthenticationManager should be composed of OAuth2ClientAuthenticationProvider (in a later story)
• the OAuth2ClientAuthenticationProvider should use the RegisteredClientRepository #40 to look up and validate the client credentials
• the RegisteredClient should be returned in a new OAuth2ClientAuthenticationToken if the authentication succeeds
• the Filter should save the OAuth2ClientAuthenticationToken in the SecurityContext
• javadoc class and public methods
• Unit tests

Specification References

2.3. Client Authentication
3.1. Token Endpoint
4.1. Authorization Code Grant
4.1.3. Access Token Request

This epic will track the progress of the following features:

#81 JSON Web Token (JWT) - RFC 7519
#81 JSON Web Signature (JWS) - RFC 7515
#82 JSON Web Key (JWK) - RFC 7517

See the ZenHub project board.

This will deliver OAuth 2.0 Token Introspection, which provides support for opaque access tokens.

It would be quite useful to support an endpoint that would issue a JWK Set. Resource servers could retrieve this JWK Set for the purpose of validating JWTs.

For this task, we will avoid providing any of our own abstractions. The result should have a Filter that works directly with Nimbus to produce an response that looks something like:

{
    "keys": [
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "257f6a5828d1e4a3a6a03fcd1a2461db9593e624",
            "kty": "RSA",
            "n": "kXPOxGSWngQ6Q02jhaJfzSum2FaU5_6e6irUuiwZbgUjyN2Q1VYHwuxq2o-aHqUhNPqf2cyCf2HspYwKAbeK9gFXqScrGLPW5pcquOWOVYUzPw87lBGH2fSxCYH35eB14wfLmF_im8DLTtZsaJvMRbqBgikM8Km2UA9ozjfK6E8pWW91fIT-ZF4Qy5zDkT3yX8EnAIMOuXg43v4t03FwFTyF4D9IET2ri2_n2qDhWTgtxJ0FHk3wG2KXdJIIVy2kUCTzMcZKaamRgUExt3Mu_z-2eyny8b6IdLPEIGF51VCgHebPQXE5iZmLGyw6M_pCApGJUw5GpXi6imo3pOvLjQ",
            "use": "sig"
        },
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "6fcf413224765156b48768a42fac06496a30ff5a",
            "kty": "RSA",
            "n": "1sUr077w2aaSnm08qFmuH1UON9e2n6vDNlUxm6WgM95n0_x1GwWTrhXtd_6U6x6R6m-50mVS_ki2BHZ9Fj3Y9W5zBww_TNyNLp4b1802gbXeGhVtQMcFQQ-hFne5HaTVTi1y6QNbu_3V1NW6nNAbpR_t79l1WzGiN4ilFiYFU0OVjk7isf7Dv3-6Trz9riHBExl34qhriu3x5pfipPT1rf4J6jMroJTEeU6L7zd9k_BwjNtptS8wAenYaK4FENR2gxvWWTX40i548Sh-3Ffprlu_9CZCswCkQCdhTq9lo3DbZYPEcW4aOLBEi3FfLiFm-DNDK_P_gBtNz8gW3VMQ2w",
            "use": "sig"
        }
    ]
}

The keys that are used can be generated at startup or be constants. The Filter might look something like this:

public class JwkSetEndpoint implements Filter {
    private final JWKSet jwks;

    public JwkSetEndpoint() {
        this.jwks = ...
    }

    public void doFilter(...) {
        if (requestMatches(request)) {
            // ... serialize jwks into a response
        } else {
            chain.doFilter ...
        }
    }
}

A Filter is a good candidate since this will play nicely with Spring Security down the road. The constructor may change in the future as other abstraction layers become clearer.

We should then have a test that asserts the endpoint works properly.

An authorization server must provide a mechanism(s) for registering Clients.

The initial implementation should provide an in-memory implementation of RegisteredClientRepository, similar to InMemoryClientRegistrationRepository in the spring-security-oauth2-client module.

Implementation Requirements

• InMemoryRegisteredClientRepository should store in a Map
• RegisteredClient should provide a Builder, similar to ClientRegistration
• RegisteredClient should be immutable
• javadoc class and public methods
• Unit tests

Specification References

2. Client Registration

An authorization server should support a /token endpoint.

On this first iteration, the endpoint should support the client credentials grant gh-5. Namely, it should verify the grant_type parameter, and formulate a JWT based on the authenticated client.

Like the JWK Set Endpoint gh-2, this should be a Servlet Filter. It will likely sit later on in the Spring Security filter chain, post-authentication. As such, it can read the current authentication from the SecurityContextHolder.

The Nimbus library should be used for generating the JWT.

The JWT should contain jti, iss, sub, exp, and iat claims. Support for scp, aud, and nbf can be added later on.

The jti claim should be a GUID. The sub claim in the JWT should be the result of Authentication#getName. The exp claim should be a reasonable time in the future, and the iat claim should be the current time when the JWT is formulated. The iss claim could be hard-coded for now.

This issue will deliver the OpenID Provider Configuration endpoint.

The security team likes to start coding by placing all the code into a sample. We later extract it out into more framework-like code.

We should begin with an empty Spring Boot sample using the latest version of Gradle, which will eventually be the home for the project's minimal authorization server sample code.

For simplicity, Java classes should be placed into a package called sample.

At this point, this sample doesn't need any MVC endpoints or other configurations.

See issue-bot for setup instructions.

Related to

It would be good to have a Resource Server sample that integrates with the authorization server sample. It should be quite similar to the Resource Server sample in Spring Security.

Like other samples, it should go into the samples directory. For simplicity, classes ought to be placed into a package called sample.

Given a valid token from the authorization server, the following test should pass:

this.mockMvc.perform(get("/")
        .header("Authorization", "Bearer " + token))
        .andExpect(status().isOk());

This epic will deliver JSON Web Key (JWK).

After the Spring Authorization Server is announced via the blog post, we need to follow-up with:

1. Update each of the 2 previous blog posts with link to new blog post:

• https://spring.io/blog/2018/01/30/next-generation-oauth-2-0-support-with-spring-security
• https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update

2. Post a comment to the original Support OAuth 2.0 Authorization Server issue to direct users to the new repository and then close the issue.

3. Notify specific users in the community and direct them to the new repository.

4. Provide a link to the new repository in the Spring Security OAuth project page.

5. Add a note/link to the OAuth 2.0 Features Matrix

6. Announce on Gitter

An authorization server should support the /.well-known/openid-configuration endpoint as specified by https://openid.net/specs/openid-connect-discovery-1_0.html.

This enables automatic client configuration (as already implemented in spring security 5) and we can also integrate JWKS endpoint as of gh-2.

The Nimbus SDK may be used for generating the endpoint response.

When a PR is submitted, we should test any changes by running the build.
The status of build should appear in the UI for the pull request.

In order to ensure OpenID Connect compatibility, one should periodically run the certification tests from: https://openid.net/certification/

This epic will track the progress of the following feature:

Provide a domain model for a client registration and authorization-related data associated between a client and a resource owner.

This epic is divided into multiple issues, in order to support parallel work streams.

#40 Implement Client Registration Model / Repository
#43 Implement Authorization Model / Service

See the ZenHub project board.

When the token endpoint from gh-3 is invoked, we will need to validate client credentials (we can add other grant types later). For this issue, we can use a hard coded client credentials. The idea is to keep this as simple as possible. We should validate every aspect of the client credentials grant type.

We should produce tests that verify the behaviour

This issue will deliver Proof Key for Code Exchange (PKCE).

We should setup the Gradle build to follow the conventions in Spring Security.

The gradle build should support the following modules:

core module with base package -> org.springframework.security.oauth2.server.authorization
config module with base package -> org.springframework.security.config
samples module

This will deliver OAuth 2.0 Authorization Server Metadata.

This epic will deliver JSON Web Signature (JWS).