Internal OAuth2 architecture

ModelOp follows the next security architecture:

Technical implementation details:

Main points of entry:
- OAuth2Login
- ResourceServer
For the ResourceServer implementation, the architecture supports JWT and Opaque independently.
- Jwt:
  - Token local validations performed by JWKs.
- Opaque:
  - Token validations performed by introspection; through an token introspection resolver ( in case more than one token introspection defined ).

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

  # Oauth2 Resource server PF Configuration
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://authorization.server

Opaque Token

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

spring:
  profile: secured, opaque

  # Oauth2 Resource server PF Configuration
  security:
    oauth2:
      resourceserver:
        opaque-token:
          introspection-uri: ${modelop.mm.introspection-uri}
          client-id: ${modelop.mm.client-id}
          client-secret: ${modelop.mm.client-secret}

Opaque Query Param

Opaque Query Param RS uses an introspection endpoint to validate the token.

JWT detailed architecture overview

Opaque detailed architecture overview

Multiple Authorization Servers architecture

Jwt & Opaque token interactions with Security Conext Holder