Best Of

Resolved — Full Working Solution (Content Server 23.1 + OTDS 23.1.8)

After extensive testing I was able to get OTDS-based user impersonation working with Content Server 23.1. Here is the complete solution for anyone else hitting this issue.

The Core Problem

The OAuth2 token exchange grant type (urn:ietf:params:oauth:grant-type:token-exchange) is not the right approach for impersonation in this context, even though OTDS partially supports it. Instead, you need to use the OTDS legacy REST authentication endpoints directly with an OTDS SSO ticket.

Two important clues that point to this:

• The token-exchange grant type does not appear in the OTDS OIDC discovery endpoint's grant_types_supported list at /otdsws/.well-known/openid-configuration
• The KB article KB0717615 (legacy KB8295770) explicitly states that for OTDS-synced users you must use /authentication/ticketforuser or /authentication/resource/ticketforuser

The Working Flow — 3 Steps

Step 1 — Get an OTDS SSO Ticket for the Service Account

Use the /authentication/credentials endpoint — NOT the OAuth2 /oauth2/token endpoint. This returns a legacy *OTDSSSO* or *VER2* format ticket rather than a JWT.

POST /otdsws/rest/authentication/credentialsContent-Type: application/json{  "userName": "YOUR-SERVICE-ACCOUNT@OAuthClients",  "password": "YOUR-CLIENT-SECRET"}

PowerShell:

$auth = Invoke-RestMethod -Method Post `  -Uri "https://YOUR-OTDS/otdsws/rest/authentication/credentials" `  -ContentType "application/json" `  -Body '{"userName":"YOUR-SERVICE-ACCOUNT@OAuthClients","password":"YOUR-SECRET"}'

The response includes a ticket field starting with *OTDSSSO* or *VER2*. This ticket can be reused to generate multiple impersonated tickets until it expires (1 hour).

Step 2 — Get an Impersonated Ticket for a Specific User

POST /otdsws/rest/authentication/ticketforuserContent-Type: application/json{  "ticket": "TICKET-FROM-STEP-1",  "targetResourceId": "YOUR-CS-RESOURCE-ID",  "userName": "USERNAME@PARTITION-NAME"}

PowerShell:

$impersonated = Invoke-RestMethod -Method Post `  -Uri "https://YOUR-OTDS/otdsws/rest/authentication/ticketforuser" `  -ContentType "application/json" `  -Body (ConvertTo-Json @{    ticket=$auth.ticket    targetResourceId="YOUR-CS-RESOURCE-ID"    userName="USERNAME@PARTITION-NAME"  })

Note: The userName must include the OTDS partition name appended with @. For example: myuser@Non-Sync Users - DEV. The exact spelling and case must match what appears in the OTDS admin console under Users & Groups. To get your Content Server Resource ID (no auth required): https://YOUR-CS/otcs/cs.exe?func=otdsintegration.getresourceid

Step 3 — Call Content Server with the Impersonated Ticket

Use a GET request with the ticket as an OTDSTicket header — not in the POST body.

GET /otcs/cs.exe/api/v1/nodes/2000OTDSTicket: IMPERSONATED-TICKET-FROM-STEP-2

PowerShell:

Invoke-RestMethod -Method Get `  -Uri "https://YOUR-CS/otcs/cs.exe/api/v1/nodes/2000" `  -Headers @{OTDSTicket=$impersonated.ticket}

Important: OTDS tickets are single-use. You must request a fresh impersonated ticket for each Content Server session. The Step 1 ticket can be reused until it expires to generate multiple impersonated tickets.

Required OTDS Configuration

Critical — otdsadmins membership is required: The service account must be a member of the otdsadmins@otds.admin group. Without this you get error 1012: "Impersonator must be a resource or an OTDS administrator". The ticketforuser endpoint enforces this check — there is no way around it for OAuth client accounts. Adding the OAuth client to otdsadmins is the correct and necessary configuration.

Note: we tested whether creating a separate OTDS resource for the service account would work as an alternative to otdsadmins membership — it does not, because the authentication is still performed as the OAuth client identity, not as the resource. The otdsadmins membership is required.

Error Reference

Reference

OpenText KB article KB0717615 (legacy ID KB8295770) — "Content Server - SDK - How to use Impersonate User using REST API to create an item as a specific user" — confirms that for OTDS-synced users, the OTDS /authentication/ticketforuser endpoint is the correct approach.