OAuth 2.0

Outcome: Design or review OAuth 2.0 for this system while keeping data correct, secure, and easy to operate. User context: A photo-printing app sends a customer to the photo service's authorization page and uses Authorization Code with PKCE. It checks `state` and the exact redirect URI, then gets a token limited to `photos.read`. Access can be revoked, and the printer never sees the customer's password. Technical concept or control: OAuth 2.0. Why it fits: Use it to give limited API permission through a trusted authorization server. Follow current security guidance for that kind of client. Do not use it when: OAuth is not user authentication. Do not put bearer tokens in URLs, use Implicit Flow in new systems, or invent your own grant type. 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): The standard covers only the listed scope. It does not choose the visual style, product decision, or Vibulary example. 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.