...

...

...

...

...

...

Context - Spring + OAuth2

Securing the ID Token

Current (Keycloak) Auth Flow

Notes: Current implementation is specific to either Keycloak or Cognito flow, not necessarily generic to auth providers

Proposed TIS OAuth2 Flow

To implement a more generic OAuth2 flow, the filter chain in the web security config will be changed to use the Spring Security oauth2Login provider as below:

...

• 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

Service-Specific Configuration

Given the above, each service would need to be configured with the following application properties:

...

In theory, this implementation should support any OAuth2 Provider with only configuration changes

Tickets

• 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)