How should authentication and authorization be represented in the architecture?

How should authentication and authorization be represented in the architecture?

Authentication establishes who a caller is. Authorization determines whether that caller may perform a particular action on a particular resource. An architecture document should explain both as explicit responsibilities, not hide them behind a single box labeled login.

Draw the identity and session flow

Show how sign-in reaches the identity system, how the application establishes a session, and how server operations identify the caller. Include session expiration, sign-out, and failure behavior so developers know what happens beyond the successful login screen.

Record where credentials and session secrets are held. Diagrams should distinguish trusted server-side components from values the browser supplies.

Define permissions around resources

An organizer may manage a wedding, a collaborator may handle assigned tasks, and a guest may respond to an invitation. These are example policies that must be agreed for the product.

A person can have different roles in different weddings. Therefore, checking a global role alone may be insufficient. An event update should verify the session, the person's membership in the target wedding, the event's wedding association, and permission for the requested change.

Enforce rules at server entry points

Hiding buttons and redirecting pages can improve the experience, but those interface checks do not secure direct server requests. Next.js likewise advises treating Route Handlers as public endpoints and checking authorization where access occurs. Next.js authentication guidance

Document a shared permission layer and require relevant entry points to use it. Include tests for an expired session, a removed collaborator, and an identifier belonging to another wedding. Ask AI to inspect these flows for missing checks, then have a developer verify the implementation against the agreed policies.