Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptSecurity conceptChapter III · Security · Building block 6 of 7

Authentication

A service must establish whether a caller controls the claimed identity.

By Michael Meierhoff · Meierhoff Systems

  1. ClaimClaim: A subject claims an identity.
  2. ProofProof: A factor or credential proves control.
  3. SessionSession: The result is securely bound to later requests.

Context

Why this is important

Establish identity traceably at trust boundaries.

Establish identity traceably at trust boundaries.

Shop example · Mapping

Authentication: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A customer signs in to the shop with a passkey. The identity provider verifies the cryptographic proof and issues a short-lived session token, which the shop validates on later requests. The order service now knows the authenticated user but still applies its order rules to decide which order may be shown. The team limits token lifetime, protects session cookies, and records failed sign-ins without storing secrets.

This is how you read the picture

  1. Claim Claim
  2. Proof Proof
  3. Session Session
Authentication: inspect the decision
ConceptMeaningReview question
ClaimA subject claims an identity.How does the customer prove identity?
ProofA factor or credential proves control.Which trust checks occur before using a token?
SessionThe result is securely bound to later requests.Which question does sign-in alone not answer?
Die Authentifizierung beantwortet eine Identitätsfrage. Sie erteilt keine fachliche Berechtigung; diese folgt einer separaten Autorisierungsentscheidung und einem klaren Vertrauensmodell für Tokens und Sitzungen. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Establish identity traceably at trust boundaries.
  • Define identity proof, token trust, and session lifetime separately.

Boundaries

  • A valid sign-in does not answer an authorization question.
  • Identity credentials need secure issuance, validation, expiry, and revocation across the trust path.

In practice

  1. Document which passkey assertion the identity service verifies and which shop components receive a short-lived session token.
  2. Test invalid, expired, and revoked tokens as well as reauthentication; check that every shop request reliably validates identity and token issuer.
  3. Check cookie protections, token lifetime, and failure logs, and confirm that neither passkey secrets nor complete session tokens appear in logs.
Read the detailed explanation

Authentication verifies whether a user, service, or device controls the claimed identity. Credentials such as passkeys, certificates, or short-lived tokens are validated and an outcome is established for later interactions.

Authentication answers an identity question. It grants no business permission; that follows from a separate authorization decision and a clear trust model for tokens and sessions.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. A customer signs in to the shop with a passkey. The identity provider verifies the cryptographic proof and issues a short-lived session token, which the shop validates on later requests. The order service now knows the authenticated user but still applies its order rules to decide which order may be shown. The team limits token lifetime, protects session cookies, and records failed sign-ins without storing secrets. auth and authorization help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    How does the customer prove identity?

    View the solution with justification

    With a passkey, which establishes a short-lived shop session.

  2. ApplyingTransferred to a new situation

    Which trust checks occur before using a token?

    View the solution with justification

    Validate issuer, signature, audience, expiry, and revocation status.

  3. EvaluateWeighing an alternative

    Which question does sign-in alone not answer?

    View the solution with justification

    Whether the customer or support may change a particular resource.

Explore further

These building blocks continue the thoughts of this page.

SecurityIdentity & PermissionsContext and comparisonOpening SecurityAuthorizationConceptual connectionOpening SecurityLeast PrivilegeConceptual connectionOpening

References

Continue on the learning path

Next in Security & Trust Boundaries: Secrets Management.

7 Building blocks

Continue withSecrets Management