OTDS OAuth2 Token Exchange — "User cannot be impersonated in resource Content Server" error despite

Layne1

Hi all,

I'm trying to authenticate to the Content Server REST API using the OTDS OAuth2 token exchange flow (client credentials → impersonate a user → access Content Server). I've done a lot of research and testing but I'm stuck on a persistent error and would appreciate any guidance.

Goal:
Use an OAuth2 service account to get a user-scoped token for Content Server without authenticating directly with a username and password.

Environment:

• OTDS: otds.yourcompany.com
• Content Server: otcs.yourcompany.com
• Content Server Resource ID: YOUR-RESOURCE-ID (retrieved via ?func=otdsintegration.getresourceid)

What works:

• Step 1 — Getting a client credentials token from OTDS works fine
• Step 2 — Token exchange without the resource scope returns a token successfully
• Direct Content Server auth with username and password works fine

What fails:
Token exchange with resource scope returns: "User cannot be impersonated in resource Content Server"

Token exchange request:
POST /otdsws/oauth2/token
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:access_token
client_id=my-oauth-client
client_secret=***
subject_token=testuser@yourcompany.com
subject_token_type=urn:opentext.com:oauth:string:user_id
scope=resource:YOUR-RESOURCE-ID

Everything I've configured in OTDS:

• OAuth client: Allow Impersonation = enabled, Confidential = enabled
• Access Role "Access to Content Server": user partition added, user added explicitly, Content Server resource added
• Content Server resource Impersonation Settings: "Allow this resource to impersonate users" = checked
• Tried OAuth client partition set to Global, user-specific partition, and non-sync partition — same error each time

Question:
Is there something on the Content Server side that also needs to be configured to allow OTDS impersonation? Or is there another OTDS setting I'm missing? Any guidance appreciated!

Layne1

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

Setting	Value	Where to configure
OAuth client — Allow Impersonation	Enabled	OAuth Clients → your client
OAuth client — Confidential	Enabled	OAuth Clients → your client
Service account in otdsadmins group	Required — see note below	Users & Groups → otdsadmins@otds.admin → Add Member
Access Role — User Partition	Add partition containing users to impersonate	Access Roles → Access to Content Server → User Partitions tab
Access Role — Resources	Add Content Server resource	Access Roles → Access to Content Server → Resources tab
CS Resource Impersonation	"Allow this resource to impersonate users" checked	Resources → Content Server → Actions → Impersonation Settings

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

Error	Cause	Fix
1009 Invalid parameter	Username format wrong or OAuth client partition mismatch	Use username@partition format; set OAuth client partition to Global
1012 Impersonator must be a resource or OTDS administrator	Service account not in otdsadmins group	Add service account to otdsadmins@otds.admin group
invalid_scope: User cannot be impersonated in resource	Resource impersonation not enabled, or using wrong grant type	Enable "Allow this resource to impersonate users"; switch to credentials endpoint approach described above
1015 Replay detected	OTDS ticket reused — tickets are single use	Request a fresh impersonated ticket for each session
Authentication Required (Bearer token)	Passing JWT to CS instead of OTDS SSO ticket	Use credentials endpoint (Step 1) to get SSO ticket, not OAuth2 token endpoint
username/password required on CS auth	Passing ticket in POST body instead of header	Use GET request with OTDSTicket as header

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.