ADR 0011. IAM Authenticates; PlayerPal Owns the Identity Graph

Status

Accepted.

Context

PlayerPal needs passkeys, social OIDC, MFA, enterprise SSO and machine OAuth. Implementing those protocols in product code is expensive and fragile. Using the IAM user record as the PlayerPal player would couple loyalty, aliases and consent to a vendor schema, force an IAM lookup on gameplay events, and make email-shaped IAM profiles hard to avoid.

Decision

Use a mature IAM platform (Keycloak initially, ZITADEL evaluated) for authentication protocols, credentials, federation, sessions and token issuance.

PlayerPal remains authoritative for:

• private pp_plr_... players
• mapping iss + sub to players
• pairwise aliases, consent, link/unlink/merge
• loyalty ownership, analytics and business authorization

The IAM subject is not the PlayerPal player. Product records reference PlayerPal player IDs, not IAM database IDs. IAM integration sits behind an adapter.

Keycloak versus ZITADEL is a proof of concept, not this ADR. The POC must satisfy spec §23.2 (passkey without email, filtered social claims, exportable mappings, separate admin/player policies).

Consequences

• IAM outages must not block already accepted ingestion or gameplay.
• Loyalty, aliases and gameplay facts must not be stored as IAM attributes, groups or roles.
• Switching IAM vendor later is possible if mappings keep issuer and subject semantics.
• See docs/authentication.md and spec §5-§6.

Amendment

Local/dev POC IAM is ZITADEL (ADR 0021). Production vendor choice remains the §23.2 checklist, not this ADR.