You can provide the following bean:

    @Bean
    public AuthorizationServerSettings authorizationServerSettings() {
        return AuthorizationServerSettings.builder()
                .tokenEndpoint("/whatever/oauth2/token")
                .build();
    }

See Configuration Authorization Server Settings in the reference.

Hi! I am updating an application with custom spel methods from spring security 5.7 to 6.
The custom method is used in annoations (@PreAuthorize) and in the security config with .antMatcher(...).access(...)

The custom spel method was implemented using these classes:

• CustomSecurityExpressionRoot extends WebSecurityExpressionRoot
• CustomWebSecurityExpressionHandler extends DefaultWebSecurityExpressionHandler
• SecurityExpressionHandler extends DefaultMethodSecurityExpressionHandler

When updating to spring security 6 i replaced the CustomSecurityExpressionRoot with a custom AuthorizationManager.
I can use this using static helper methods in the security config. But what has to be done to make it usable in spel string in @PreAuthorize?

This is a good question, and one that perhaps would be worth reiterating on StackOverflow if we find a good answer for you (assuming it hasn't already been asked/answered).

First, I would recommend considering a thorough review of the 5.8 migration guide, specifically the authorization section. Often, it is easier to take a 5.7 release, upgrade it to 5.8, and only work on migrating one aspect of your application at a time using the steps outlined in the guide. The 5.8 release was designed specifically for helping you migrate to 6.0 one piece at a time. It sounds like you aren't struggling with this, but I thought I'd mention it in case you weren't aware.

Second, check out the Customizing Authorization section of the Method Security chapter. After enabling method security (@EnableMethodSecurity), you can register your MethodSecurityExpressionHandler as an @Bean, as in:

@Bean
static MethodSecurityExpressionHandler methodSecurityExpressionHandler() {
    // ...
}

Note: Per the docs, the static is important for ordering.

Hi @sjohnr,

thanks for your reply. I think my question wasn't worded very precisely.

As mentioned, i already implemented a custom MethodSecurityExpressionHandler and i can use the custom method in spel in annotations.

But i wonder if there is a way or an implementation advice to reuse the implementation of the AuthorizationManager for method security annotations? Otherwise i have a lot of boilerplate code to support custom methods for spel, that can be used in annoations or in the security config via static helper methods.

I see @marbon87. Just below in the chapter I linked in the reference docs, you see Custom Authorization Managers which does talk about this topic.

In this case, you would have two different types of AuthorizationManagers, one for requests, another for method security. They take different parameters since the method security one operates on a MethodInvocation. Additionally, replacing the @PreAuthorize handling would disable SpEL support, unless you work to support it AND your custom implementation. So while it's possible, I think it has tradeoffs to consider.

I could be wrong, but I think supporting a custom MethodSecurityExpressionHandler is still worthwhile if you plan to use @PreAuthorize often. Hopefully, I'm not missing any detail here.

Thanks for your willingness to contribute!

We add things into the DSL reluctantly because we are aware of its learning curve. Unless something is a lot easier to configure with the DSL, then we leave it out. It seems to me that RequestHeaderAuthenticationFilter has two setters and otherwise is pretty easy to drop into .addFilterAt, so I'd personally lean against adding it.