A new boolean field, useAuthorizationClaim, will be added to each element of the oidcIdentityProviders server parameter. The default value of this field will be true.
When useAuthorizationClaim is set to false, the authorizationClaim field of the oidcIdentityProviders server parameter is not expected to be provided as part of the configuration. This effectively enables internal authorization for all access tokens representing users from that identity provider.

A new boolean field, supportsHumanFlows, will be added to each element of the oidcIdentityProviders server parameter. The default value of this field will be true.
When supportsHumanFlows is set to false, the clientId field of the oidcIdentityProviders is not expected to be provided as part of the configuration.
When supportsHumanFlows is set to false, the matchPattern field of the oidcIdentityProviders setParameter is optional. If there is just one IdP with supportsHumanFlows: true, then matchPattern is optional for that IdP, too, and any principal name hints will result in that human flow IdP's registration being returned to the driver. If there is more than one IdP with supportsHumanFlows: true, then matchPattern is mandatory for all of those IdPs.

When authenticating to a server with MONGODB-OIDC, the server's first step SASL reply may omit `clientId` if the provided principal name hint matches an IdP with `supportsHumanFlows: false`. The server also will not consider any machine flow IdPs that have did not supply a `matchPattern` when selecting an IdP configuration to return for the first SASL reply.

The exact-match usersInfo command will include an additional field called authorizationProvider that can resolve to one of

. When provided, the server will attempt to resolve the user's roles using the requested authorization provider and return an error otherwise.

Description of Linked Ticket

Summary

This project will introduce support for internal authorization for OIDC authenticated clients. An administrator will be able to create user documents in the $external database which will represent the identities and privileges which end-users may acquire through OIDC authentication.

Motivation

Workload identities are, by definition, used in a single context. Their required privileges can be enumerated up front, and only change as a result of a concerted engineering effort. We can simplify the workload identity federation process by allowing administrators to directly create the identities they need and statically enumerate their privileges.

Documentation

Product Description
Scope
Technical Design
Docs Update