Accounts and Identities for the Authorization Server

The hosted authorization server distinguishes two kinds of principals, with different rules:

• Platform administration uses operator accounts that live in the EDK identity store. The platform owner is provisioned during platform tenant bootstrap as a natural person with an identity and protected email identifier, and the credential is written through the hosted AS credential store. The operator signs in through the hosted AS form flow described on the operator sign-in page. Platform administration does not use federated sign-in: the platform AS is an internal authorization server whose sole job is providing admin accounts for platform management, and it is intentionally kept minimal.
• Tenant users authenticate according to the hosted resource's LOCAL_ONLY, FEDERATED_ONLY, or HYBRID mode. Local identities are UUID-scoped application bindings with revision-guarded enabled state and roles. Federated authentication uses an enabled binding to a validated external OpenID Connect resource and retains governed claim provenance. An upstream provider remains authority for its subject; the hosted server does not silently merge it with a local identity.

Client and identity administration is nested below /api/platform/config/v1/tenants/{tenantId}/authorization-servers/{authorizationServerId}. Confidential client values are write-once and reads return only typed references. Identity role and enabled-state changes are atomic and record pending session revocation durably.

The authorization code flow page shows how an authenticated user drives credential issuance.