-
Notifications
You must be signed in to change notification settings - Fork 6.1k
OAuth 2.0 Migration Guide
This document contains guidance for moving from Spring Security OAuth 2.x to Spring Security 5.2.x.
Because the two approaches are as different as they are, this document will tend to cover patterns more than precise search-and-replace steps.
Spring Security takes a slightly different approach from Spring Security OAuth in a few notable ways.
Spring Security OAuth exposes two different DSLs for Resource Server. These are configured by extending ResourceServerConfigurerAdapter.
Spring Security exposes the same functionality via the Spring Security DSL, which is configured by extending WebSecurityConfigurerAdapter.
Spring Security OAuth’s Resource Server support is enabled by adding the @EnableResourceServer annotation.
Spring Security’s Resource Server support is enabled via the Spring Security DSL.
Spring Security OAuth indicates two locations for specifying authorization rules. The first is via ResourceServerConfigurerAdapter - any rules supplied here are for when a bearer token is present. The second is via WebSecurityConfigurerAdapter - any rules supplied here are for requests where a bearer token is absent.
Spring Security indicates that all authorization rules be configured via one or many WebSecurityConfigurerAdapter s.
Spring Security OAuth supports a custom SpEL variable called oauth2.
To authorize requests or methods based on scope, you write an expression like access("#oauth2.hasScope('scope')").
Spring Security converts scopes that follow the granted authority naming convention.
To authorize requests or methods based on scope, you write an expression like hasAuthority("SCOPE_scope").
Both Spring Security and Spring Security OAuth2 have examples for how to configure Resource Server:
| Use case | Spring Security | Spring Security OAuth |
|---|---|---|
JWT + JWK |
||
JWT + Key |
||
Opaque Token |
||
w/ Actuator |
||
Audience Validation |
||
Authorizing Requests |
There are some features that we currently have no plans to port over.
In Spring Security OAuth, you can configure a UserDetailsService to look up a user that corresponds with the incoming bearer token.
There are no plans for Spring Security’s Resource Server support to pick up a UserDetailsService.
This is still simple in Spring Security, though, via the jwtAuthenticationConverter DSL method. Notably, one can return a BearerTokenAuthentication which takes an instance of OAuth2AuthenticatedPrincipal for a principal.
In Spring Security OAuth, you can assign an identifier to the resource server via the ResourceServerSecurityConfigurer#resourceId method. This configures the realm name used by the authentication entry point as well as adds audience validation.
No such identifier is planned for Spring Security.
However, audience validation and a custom realm name are both simple to achieve by configuring an OAuth2TokenValidator and AuthenticationEntryPoint respectively.