OpenID Connect

Outcome: Design or review OpenID Connect for this system while keeping data correct, secure, and easy to operate. User context: An HR portal finds its company issuer, sends `nonce` and `state`, and receives an ID Token. It checks the signature, issuer, audience, expiry, and `nonce`. Then it uses `sub` as the stable user ID. Email is only display data. API calls still use a separate access token. Technical concept or control: OpenID Connect. Why it fits: Use it for shared sign-in when an app needs standard identity claims from an OpenID Provider. Do not use it when: Never accept an ID Token without every required check. Do not use it as an API access token or treat identity facts as permission by themselves. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): A formal document may still be a draft, release candidate, or final version. Check its status and browser or platform support. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.