Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -291,4 +291,91 @@ a|authentication.json
|===
In general, if you add a custom property, the Admin UI writes changes to the `authentication.json` or `ui-configuration.json` files.

[#oauth-module-details]
=== OAUTH Module Configuration Options

The `OAUTH` module authenticates users via a generic OAuth 2.0 provider. It validates an OAuth 2.0 `access_token` by calling the provider's `userinfo_endpoint`. Two HTTP headers are required: one carrying the token and one naming the provider resolver. For more information, see xref:chap-auth.adoc#oauth-module["OAUTH"].

[#table-oauth-module-prop]
.OAUTH Module Properties
[cols="28%,29%,43%"]
|===
|Authentication Property |Property as Listed in the Admin UI |Description

a|`enabled`
a|Module Enabled
a|Whether OpenIDM uses the module.

a|`authTokenHeader`
a|OAuth Token Header
a|Name of the HTTP request header that carries the OAuth 2.0 access token. This header is required; authentication fails if it is absent.

a|`authResolverHeader`
a|OAuth Resolver Header
a|Name of the HTTP request header that identifies the provider resolver to use. The value must match the `name` of an entry in the `resolvers` array. This header is required.

a|`queryOnResource`
a|Query on Resource
a|Managed object endpoint to query after the token is validated against the provider (for example, `managed/oauth`).

a|`propertyMapping.authenticationId`
a|Authentication ID
a|Attribute in the managed object used as the user identifier.
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The appendix defines two different fields named “authenticationId” at different levels, but doesn’t explicitly state that they refer to different sources (managed object attribute vs. userinfo response attribute). Adding a brief clarification (or renaming the description wording to explicitly call out “managed object attribute” vs “provider userinfo attribute”) would prevent misconfiguration—especially since both are labeled “user identifier.”

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot apply changes based on this feedback

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 67d1349 — updated the propertyMapping.authenticationId description in the module-level table to explicitly state it is the managed object attribute (e.g., userName) used when querying queryOnResource, and that it is distinct from the resolver-level authenticationId which names the field in the provider's userinfo endpoint response.


a|`propertyMapping.userRoles`
a|User Roles
a|Attribute in the managed object used for authorization roles (for example, `authzRoles`).

a|`defaultUserRoles`
a|Default User Roles
a|Roles assigned to all users who authenticate successfully through this module.

a|`augmentSecurityContext`
a|Augment Security Context
a|Optional script executed after a successful authentication request.
|===
Comment thread
vharseko marked this conversation as resolved.
Outdated

[#table-oauth-resolver-prop]
.OAUTH Resolver Properties (within `resolvers[]`)
[cols="30%,70%"]
|===
|Property |Description

a|`name`
a|Unique resolver name. The value sent in the `authResolverHeader` HTTP header must match this name.

a|`type`
a|Always `OAUTH`.

a|`client_id`
a|OAuth 2.0 client ID registered with the provider.

a|`client_secret`
a|OAuth 2.0 client secret registered with the provider.

a|`authorization_endpoint`
a|Provider's authorization endpoint URL.

a|`token_endpoint`
a|Provider's token endpoint URL.

a|`userinfo_endpoint`
a|Provider's userinfo endpoint URL. The access token is validated by calling this endpoint.

a|`scope`
a|List of OAuth 2.0 scopes to request (for example, `["openid", "profile", "email"]`).
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example scope includes openid, which is typically associated with OpenID Connect. Since this section explicitly distinguishes OAUTH from OPENID_CONNECT, consider using a non-OIDC example (for example, ["profile", "email"]) to avoid confusing readers.

Suggested change
a|List of OAuth 2.0 scopes to request (for example, `["openid", "profile", "email"]`).
a|List of OAuth 2.0 scopes to request (for example, `["profile", "email"]`).

Copilot uses AI. Check for mistakes.

a|`authenticationId`
a|Attribute from the userinfo endpoint response used as the user identifier (for example, `_id` or `sub`).
Comment thread
vharseko marked this conversation as resolved.
Outdated

a|`propertyMap`
a|Array of `{source, target}` pairs that map attributes from the provider's userinfo response to attributes on the managed object.

a|`icon`
a|HTML markup for the social login button displayed in the UI.

a|`enabled`
a|Whether this resolver is active.
|===


60 changes: 60 additions & 0 deletions openidm-doc/src/main/asciidoc/integrators-guide/chap-auth.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -480,6 +480,66 @@ Set up logins with OpenAM, to work with the related login session cookie, known
IWA::
The IWA module enables users to authenticate by using Integrated Windows Authentication (IWA), rather than by providing a username and password. For information about configuring the IWA module with OpenIDM, see xref:#openidm-auth-kerberos["Configuring IWA Authentication"].

[#oauth-module]
OAUTH::
The `OAUTH` module authenticates users via a generic OAuth 2.0 provider by validating an OAuth 2.0 `access_token` against the provider's `userinfo_endpoint`. Unlike the `OPENID_CONNECT` module, it does not use JWT identity tokens.
+
The module requires two HTTP request headers:
+
* `authTokenHeader` — carries the OAuth 2.0 access token.
* `authResolverHeader` — names the provider resolver (from the `resolvers` list) that should validate the token.
Comment thread
vharseko marked this conversation as resolved.
Outdated
+
Using two headers allows a single module instance to support multiple OAuth providers simultaneously, each defined as a separate entry in the `resolvers` array.
+
The following sample configuration shows the `OAUTH` module with a single provider resolver:
+
[source, json]
----
{
"name" : "OAUTH",
"enabled" : true,
"properties" : {
"augmentSecurityContext": {
"type" : "text/javascript",
"file" : "auth/populateAsManagedUserFromRelationship.js"
},
"propertyMapping" : {
"userRoles" : "authzRoles",
"authenticationId" : "_id"
Comment thread
vharseko marked this conversation as resolved.
Outdated
},
"defaultUserRoles" : [
"openidm-authorized"
],
"resolvers" : [
{
"name" : "myProvider",
"type" : "OAUTH",
"icon" : "<button class=\"btn btn-lg btn-default btn-block btn-social-provider\"><img src=\"images/provider.png\">Sign in with Provider</button>",
"scope" : ["profile", "email"],
"authenticationId" : "_id",
"propertyMap" : [
{
"source" : "sub",
"target" : "userName"
}
Comment thread
vharseko marked this conversation as resolved.
],
Comment on lines +514 to +525
Copy link

Copilot AI Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sample mixes two different “identity” fields without explaining how they relate: resolver authenticationId/propertyMap.source uses sub, but propertyMapping.authenticationId is set to _id while the mapped managed attribute target is userName. This makes it unclear which managed attribute is intended to be the effective authentication identifier. Consider aligning the example (e.g., set propertyMapping.authenticationId to userName if that’s the mapped identifier) and/or adding a short note explaining the distinction between resolver authenticationId (userinfo response field) and propertyMapping.authenticationId (managed object field).

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot apply changes based on this feedback

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in 80818d2propertyMapping.authenticationId is already "userName" (consistent with the propertyMap target userName), and added a note after the sample explaining that authenticationId means different things at the two levels: inside resolvers[] it refers to the provider's userinfo response field (e.g., sub), while at propertyMapping level it refers to the managed object attribute used as the authentication identifier (e.g., userName).

"enabled" : true,
"client_id" : "your-client-id",
"client_secret" : "your-client-secret",
"authorization_endpoint" : "https://provider.example.com/oauth2/authorize",
"token_endpoint" : "https://provider.example.com/oauth2/access_token",
"userinfo_endpoint" : "https://provider.example.com/oauth2/userinfo"
}
],
"queryOnResource" : "managed/oauth",
"authTokenHeader" : "authToken",
"authResolverHeader" : "provider"
}
}
----
+
For detailed property descriptions, see xref:appendix-auth-modules.adoc#oauth-module-details["OAUTH Module Configuration Options"].

--


Expand Down
Loading