Context - Spring + OAuth2

...

• Retrieve the appropriate claim from the token to be matched with the username in the profile service

• Verify the user exists, and retrieve the user’s roles and principles for authorization

• Set the calling service’s security context with the retrieved authorities (do we want to do this?)#

A high level idea of this can be seen below:

...

1. SharedAuthencticationSuccessHandler (implements AuthenticationSuccessHandler) (needs new name)

   • Instantiated with following dependencies/params:

     • SecurityContext(is this bad?) - for setting granted authorities

     • JwtUtil(another shared component, see below) - for decoding token to retrieve user details

     • UserDetailsService - for retrieving user details

   • Does the following in its onAuthenticationSuccessmethod:

     • Decodes token to find username (email) using JwtUtil

     • Fetches user details from UserDetailsService

     • Extracts granted authorities from UserInfo and sets them in SecurityContext

     • Authorization can now be performed on controllers etc within the calling service

2. JwtUtil class (again, needs a better name)

   • Instantiated with the following dependencies/params:

     • jwkSetUri String configured as an application property

     • jwtIssuer String configured as an application property

     • usernameClaimString configured as an application property (this is because we use email as the username)

     • creates a NimbusJwtDecoder Bean from jwkSetUri and jwtIssuer

   • Does the following:

     • Method to retrieve the username from the token

   • UserDetailsService - Already exists, fetches user infor by user name

...

• One Ticket to implement the new Shared Components (enough of a vertical slice?)

• One Ticket per service to switch over configuration (possibly with different subtasks depending on authorization/redirect requirements of each service)

Questions: how are subsequent requests from a UI application handled?