Create a Player session

Before integrating, obtain a dedicated Player-session credential through the organization-administrator credential-management workflow supplied for your environment. Tenant Management returns its plaintext only when the credential is created; store that value immediately in your backend secret manager. It is separate from API keys and can only create sessions. The current Dashboard UI does not expose self-service controls for this credential.

curl -X POST "$IDENTITY_API_URL/player/v1/sessions" \
  -H "Authorization: Bearer $PLAYER_SESSION_CREDENTIAL" \
  -H "Content-Type: application/json" \
  -d '{"externalPlayerId":"customer-player-42","displayName":"Aster"}'

externalPlayerId is your stable tenant-scoped identifier, not a Tanitar Player id. Tanitar stores digest material and does not expose it in tokens or logs. displayName is optional and applies only on first creation. Concurrent first assertions converge on one Player and provisioning operation.

The response contains accessToken, expiresAt and Tanitar's playerId. The token lasts 15 minutes and carries a closed context: sub, account_id, iat, exp, jti, Tanitar issuer and Player audience. It carries no customer issuer, external identifier, membership, tier or scope.

Return the token through your authenticated backend, keep it in memory, and use Authorization: Bearer ... on allowlisted /player/v1/* routes. Never put either credential in a URL, cookie, local storage or log. Repeat the backend assertion before expiry; there is no refresh token. The session route deliberately has no browser CORS permission.

Revoking the credential prevents the next session. Distributed limits fail closed when their counter store or control plane is unavailable. See Error codes. To replace a credential, create another credential through the same management workflow, deploy it, then revoke the old one. Player-session credentials do not have a rotation operation.