Internal OAuth2 architecture

ModelOp Center adheres to the Spring Security Architecture for OAuth2 applications.

The next diagram provides a high level overview of the internal layers.

 

 

ModelOp Center supports ServerHttpSecurity configurations as:

  • OAuth2Login (C2B):

    • Mainly used by the Gateway, handling browser authentication.

  • ResourceServer:

    • Jwt:

      • Token local validations performed by JWKs.

    • Opaque:

      • Token validations performed by introspection; through token introspection resolvers ( in case more than one token introspection defined ).

      • Opaque-QueryParam.


Securing microservice to microservice communication

In secured environments, microservice to microservice communication or B2B communication is token protected. This process is internally managed by feign clients. Feign clients use an OAuth2 FeignInterceptor implementation in charge of requesting/refreshing tokens and adding them as headers as part of each request.

To improve performance, our FeignInterceptor is adding an additional tenant-id header inside the request, allowing downstream resource servers (RS) to identify faster the right introspector/token validator to be used at runtime, saving time and resources, specially when used with Opaque environments with multiple OAuth2 IdP defined.


Defining a MicroService as Resource Server (RS):

  1. Identify the type of tokens to be supported

  2. Define profiles accordingly

  3. 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: feign: client-id: ${modelop.mm.client-id} client-secret: ${modelop.mm.client-secret} access-token-uri: ${modelop.provider.token-uri} scopes: ${modelop.mm.scope} group-base-access: oauth2-group-claim-name: memberOf admin-default-access-group: admin default-access-groups: ${oauth2.group-base-access.default-access-group}

JWT RS configurations

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 oauth2: resource-server: jwt: enduser-claimname: endUserClaimName oauth2client-claimname: oauth2ClientName scope-claimname: scp base-conf: enduser-claimname: endUserClaimName oauth2client-claimname: oauth2ClientName

Opaque token RS configurations

At least one default RS opaque configuration is needed under

spring.security.oauth2.resourceserver.opaque-token, so that related spring OAuth2 dependencies are properly instantiated.

Default configuration example:

spring: profile: secured, opaque # Oauth2 Resource server PF Configuration security: oauth2: resourceserver: opaque-token: #Default opaque introspector introspection-uri: ${modelop.mm.introspection-uri} client-id: ${modelop.mm.client-id} client-secret: ${modelop.mm.client-secret} client-registration-id: springClientRegistrationId

client-registration-id needs to point to a valid spring client registration id.

Adding additional Opaque RS introspectors:

ModelOp Center is able to handle additional Opaque introspectors for token introspection.

These introspectors can be defined under oauth2.resource-server.opaque:

As a rule, each of the additional introspectors defined, need to be mapped with a Spring Client Registration associated with the same clientRegistrationId.

Opaque Query Param

ModelOp Center is able to support and introspect some non-standard OAuth2 idPs. By default ModelOp Center provides an implementation for a Opaque Query Param introspector, that can be defined as:


Token Claims to User Attributes Mapping

By default, ModelOp Center maps each user attribute to its corresponding standard claim. The standard claims used by ModelOp Center are defined in the OpenID Connect specification as a set of OpenID Connect Standard Claims. For the complete list of standard claims, please refer to section 5.1 Standard Claims of the OpenID Connect specification.

ModelOp Center’s default use of the standard claims can be adjusted to use other claims by adding configuration properties. For example, the standard claim for a user’s given name is given_name. However, if that particular claim is not available, one could use the username claim instead (assuming the claim is available) by adding the following configuration properties:

Please note that the configuration above is overriding one claim name only, but multiple or all claim names can be overridden, if necessary.