This module is in maintenance mode. I'm not very happy to use it as the authorization server most probably needs to be rewritten with the next spring security version (5.3)...

I wonder if there is any mock-authorization server we could use instead of rolling our own "implementation"?

Spring team prepared demo application with new OAuth2 approach some time ago. In that demo they made use of Cloudfoundry UAA

I think it depends on how easy it will be to set up authorization server using Spring Security 5.3. If it will be the matter of adding @SpringBootApplication class + application.yml, then probably we could stick to native solution.

At this moment I know nothing about 5.3, I will check it out later.

Ok, taking into consideration the fact that 5.3 is not on the horizon, and you are not quite satisfied with spring-security-oauth2-autoconfigure, I decided to update my solution and make use of Cloudfoundry UAA.

I played a bit with it, it was quite easy to setup. It supports all major grant types that we may be interested in: authorization_code, client_cridentials, password, etc.

At this point, I have just migrated already existing solution with password grant type.
If you are ok with Cloudfoundry UAA, we can close this thread and agree on grant type in another thread.

Whatever type we pick, it should be easy to change it in uaa.yml

I still think, this sample shouldn't involve cloud foundry. May be the OpenId connect Playground may prove useful

The spring security team also announced that they won't provide any authorization server. They point users to keycloak or other oidc services.

In order to make this a stand-alone experience which is good for a sample I believe it is possible to implement the authorization server application based on good old spring-security-oauth2 while the resource server and the SBA would benefit from first-class oAuth2 support in Spring5.

The spring security team also announced that they won't provide any authorization server. They point users to keycloak or other oidc services.

Could you please provide the source link? As I can see in their blog post (updated section), it seems like they changed their mind.

Anyway, I agree that this example, probably, should not focus too much on authorization server configuration - it should be more about the integration of SBA with Spring Security OAuth2.

My motivation for using Cloudfoundry UAA was the fact that it did not require an account creation on any 3rd party service in case someone wanted to run the example.

Could you please provide the source link? As I can see in their blog post (updated section), it seems like they changed their mind.

I have no other information. But currently for me their decision is unchanged.

We are no longer planning on adding Authorization Server support to Spring Security.

https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Features-Matrix

I think this sample should stick to common practices and use the authorization_code grant type.

Could you please provide an example flow? As far as I know authorization_code grant type is not well-suited for server-to-server authentication, so I try to understand your vision of how it should work step-by-step

I think we both have a different understanding of the whole picture.

In my understanding, a not logged-in user is forwarded to the configured authorization provider by SBA. The authorization token allows the user a) to use SBA and b) to use the actuator endpoints of the client applications. Therefore SBA needs to forward the authorization token in requests made to the underlying applications. This should use the authorization_code grant-type.

The SBA server does also query some endpoints in the background (e.g. /health and /info). So the SBA server needs to authenticate against the client applications. This authentication should be done via the password grant-type or using basic auth.

The SBA server does also query some endpoints in the background (e.g. /health and /info). So the SBA server needs to authenticate against the client applications. This authentication should be done via the password grant-type or using basic auth.

I don't think I follow this part. Why client applications must require an additional basic authentication in order to expose /health and /info endpoints? Should not those be in the scope of the token?

On the other hand, if SBA server is protected by OAuth2 and token is required to use it, how resource server should register itself?

I don't think I follow this part. Why client applications must require an additional basic authentication in order to expose /health and /info endpoints? Should not those be in the scope of the token?

Yeah the SBA server must have a token that allows to access these endpoints. (As alternative it might use some credentials and basic authentication to access those - think of it like an api key - which is imho easier to setup)

On the other hand, if SBA server is protected by OAuth2 and token is required to use it, how resource server should register itself?

Either just the endpoint for registering is left unprotected or the same applies here:
The sba clients either needs a oauth2 token or some other form of credentials for authentication...

I prepared an example version with the scenario you proposed, however I encountered problems during testing the solution:

1. Refreshing available actuator endpoints

Consider the following scenario:

Given:
* Authorization, SBA and Resource servers are up.
* Resource server is protected with OAuth2, but allows accessing to /health and /info endpoints with basic authentication.

When:
* Resource server registers itself using basic authentication before SBA login is performed and token is obtained.
* SBA (using basic authentication) fetches available actuator endpoints of the Resource server.
* SBA login is performed and token is obtained.

Then:
* Requests to the Resource server include Bearer token
* UI does not display all details, but only Metadata and Health
* After restarting Resource server all endpoints are displayed

Reason:
* It seems like available endpoints are not refreshed after being once fetched.

Solution:
* Well, I am not sure if there is a way to trigger a refresh. Please, advice.

2. Problem fetching OAuth2AuthorizedClient from HttpHeadersProvider

Put simply, Spring provides a mechanism to fetch client (with token) using client-id and principal, however I can not find a convenient way to obtain a principal. SecurityContextHolder.getContext().getAuthentication() returns null when called from HttpHeadersProvider.

The workaround I found for now is to implement custom in-memory OAuth2AuthorizedClientService that is able to fetch any client with suiting scope, however I am not satisfied with the solution.

Put simply, Spring provides a mechanism to fetch client (with token) using client-id and principal, however I can not find a convenient way to obtain a principal. SecurityContextHolder.getContext().getAuthentication() returns null when called from HttpHeadersProvider.

This is due to 2 facts:

1. Spring Boot Admin makes fetches in the background (without any user interaction). So SBA still need some own token. For these background fetches the easiest way would be to have some kind of basic auth using username/password or an api-token

2. Spring Boot Admin uses the WebClient for making requests. Due to the reactive nature the request ist executed in a different thread and the ThreadLocal backing the SecurityContextHolder is not available.
   If you just need access to the original headers write a InstanceExchangeFilterFunction which has access to the headers from the original request (filtered by the HttpHeaderFilter and settings from spring.boot.admin.instance-proxy.ignored-headers - defaults to "Cookie", "Set-Cookie", "Authorization").
   If you need the principal itself I guess, we could include it to the request attributes passed to the InstanceExchangeFilterFunction

If you just need access to the original headers write a InstanceExchangeFilterFunction which has access to the headers from the original request (filtered by the HttpHeaderFilter and settings from spring.boot.admin.instance-proxy.ignored-headers - defaults to "Cookie", "Set-Cookie", "Authorization").

Not sure that access to the request headers would be enough to solve the problem.

Here is how OAuth2Login works in Spring 5. The requests between SBA front and SBA back would be authorized with a Cookie. All tokens obtained from OpenID Connect provider will be stored on the backend and fetched into Authentication object by Spring Security in the context of request processing. So basically this is what you want to do inside HttpHeadersProvider (pseudo-code):

    @Bean
    public HttpHeadersProvider customHttpHeadersProvider() {
        return  instance -> {

            if (requestContext.getRoute().equals("/actuator/info") || requestContext.getRoute().equals("/actuator/health")) {
                // user-agnostic request
                // use token obtained with Client Credentials Grant
            } else {
                Authentication authentication = securityContext.getAuthentication(); // as SecurityContextHolder.getContext().getAuthentication() will not work in reactive world

                OAuth2AuthenticationToken oauthToken = (OAuth2AuthenticationToken) authentication;
                OAuth2AuthorizedClient client = authorizedClientService
                    .loadAuthorizedClient(oauthToken.getAuthorizedClientRegistrationId(), oauthToken.getName());

                httpHeaders.add(HttpHeaders.AUTHORIZATION, String.format("Bearer %s", client.getAccessToken()));
            }

Without having requestContext and securityContext defined above I cannot see how the HttpHeadersProvider could be implemented.