Nikolay's Dev Blog

 Let's say we have a typical oauth2 setup with a frontend service, an authorization server and a resource server, based on Spring Boot and using Webflux. The login of the end-user is processed using the "authorization_code" grant type. Here is how it works: 1. The user opens the URL of the frontend service in their browser (e.g. https://www.mysite.com). The frontend service redirects the user to the authorization server (e.g. https://auth.mysite.com). 2. The browser follows the redirect, opens the authorization server's URL and the user logs in with their credentials. The authorization server redirects the user back to the frontend service, including a code (authorization_code) parameter in the URL. 3. The browser follows the redirect and opens the frontend service URL. The frontend service calls internally the authorization server with the code provided and receives the access and refresh tokens. It stores them in the http session of the user. The login is completed....

As you might know, the old spring-security-oauth2-autoconfigure was deprecated and replaced by spring-security-oauth2-resource-server. Here I will try to demonstrate how to use it in a typical setup: web server (as a client, using authorization_code grant type) - authorization server - resource server, with some customization (loading additional properties from the check_token and user info endpoints). The Authorization Server A lot has been going on in the spring framework about this, so I am not going to put much details here. You can use any authorization server implementation, including the deprecated one from spring-security-oauth2 or the new one spring-security-oauth2-authorization-server or any other non-spring implementation, that follows the oauth 2.0/2.1 specification. All of the following examples are based on spring-boot and using spring-security. The Resource Server Dependencies <dependency> <groupId> org.springframework.security </groupI...