OPClientAuthentication

Current File(s): conf/oidc.properties
Format: Native Spring

Overview

Prior to V3.1, support for client authentication was hardwired to support cleartext client secrets (password) resolved from client metadata and signed JWT authentication. These features did not require or offer much in the way of configuration or customizability, save for limiting specific methods via individual profile configuration settings.

V3.1 implements client authentication using the same authentication machinery used for end-user authentication, along with a default login flow suited to most deployments. This flow, labeled “authn/OAuth2Client”, is modeled after the original Password login flow, minus the user interface. Because it is implemented separately, it supports its own configuration settings and can operate in parallel.

Configuration

As with ordinary AuthenticationConfiguration, a property exists to control the login flows enabled for OAuth client authentication and is processed as a regular expression pattern to match the enabled flows. The property, named idp.oauth2.authn.flows, defaults to “OAuth2Client” when unset, for compatibility. Also as with user authentication, the various OAuth profile configuration beans expose the interface containing various properties that can be used to directly influence authentication on a per-profile (and per-relying party) basis, but this would be very unusual.

While it is possible to change the enabled flow(s) via this property, it should be understood that each login flow operates according to whatever its configuration happens to be without regard for whether it’s used for end-user or client authentication. In most cases, it’s best to use the default login flow and use its configuration to handle anything unusual (which should hopefully be pretty rare in its own right).

Behavior

In essentially all respects, the client authentication process operates in exactly the same way as the user authentication process described in the AuthenticationConfiguration topic. This extends to:

• Running a post-login Subject Canonicalization flow to normalize the client’s “subject name”

• Producing a Java Subject containing a set of Principal objects and wrapping it in an AuthenticationResult

Most of this can be ignored in practice but there may be cases in which the normalization process is important. The thing to be aware of is that the primary input to client authentication will generally be an OAuth client_id, but this may be inconvenient to operate on internally in some cases.

For example, if you’re supporting the “client_credentials” grant type, the client_id may not match the account name under which you intend to resolve claims or implement policy, so the canonicalization layer can be applied, as with end users, to transform the client_id into something else. For protocol purposes, the client_id is still treated as the client_id when issuing tokens, resolving client metadata, etc. The separation is optional if desired.