Internal OAuth2 architecture

ModelOp follows the next security architecture:

Technical implementation details:

The architecture provides AuthenticationResolvers implementations available for MVC and Reactive environments.
Each AuthenticationResolver iterates over the list of available AuthenticationManagers trying to find the best suited to perform the local authentication/authorization for the current request in order to build the User.
Each AuthenticationManager implementation perform the next steps:
- Read and validate token.
- Get user details out of token or from User details endpoint.
- Get list of user groups.
- Get list of GrantedAuthorities.
- Upload current authenticated user into the SecurityContextHolder.
The next 3 key services are required during the local authentication/authorization and current authenticated user process:
- AccessTokenService :
  - JwtAccessTokenService
  - OpaqueAccessTokenService
- GrantedAuthoritiesService
- UserDetailsService
  - TraditionalUserDetailsService
  - IntrospectionUserDetailsService

How to define a MicroService as Resource Server (RS):

Identify the type of tokens to be supported
Define profiles accordingly
Add required YAML configurations.

Currently, three types of resource servers are supported:

JWT
Opaque Token
Opaque Query Param (This is a non-traditional type of Opaque Token required for one of our clients, and it is not used locally).

All of these resource servers share the following common configurations:

oauth2:
    resource-server:
        base-conf:
            user-info-uri: <https://pingfederate:9031/idp/userinfo.openid>
    group-base-access:
        oauth2-group-claim-name: memberOf

JWT

JWT RS is straight forward, only jwt profile is required.

spring:
  profile: secured, jwt

Opaque Token

Opaque Token RS uses an introspection endpoint to validate the token.