Starts authorization and carries browser-visible values such as client_id, state and the authorization response. It must never contain a confidential Client Secret.
Follow the sign-in path, see how sensitive data is protected, and understand what MemoID and each connected application need to verify.
Values visible to a browser must not be treated like long-lived credentials. MemoID intentionally separates public client context, application secrets, identity authority and resource authorization.
Starts authorization and carries browser-visible values such as client_id, state and the authorization response. It must never contain a confidential Client Secret.
Owns transaction state, protects confidential credentials and refresh tokens, exchanges the authorization code, validates ID-token claims, and creates the application's own session.
Authenticates the user, applies application-entry policy, records consent, issues tokens, rotates refresh tokens and publishes metadata/JWKS needed for validation.
Validates the access context and still owns business authorization: roles, tenant membership, object/resource permissions and domain rules remain the destination application's responsibility.
The visual preview focuses on where sensitive data is allowed to move. The expandable block below is the canonical Mermaid representation so reviewers can copy it into GitHub, Mermaid Live or another architecture tool without reinterpreting the flow.
Long-lived secrets should remain on protected server-side paths; browser-visible values are treated as inspectable.
flowchart LR B[Browser / Native Client\nPublic or user-controlled zone] A[Application Backend / BFF\nApplication trust zone] M[MemoID\nIdentity trust zone] R[Resource API\nResource trust zone] B -->|authorize request + state| M M -->|authorization code + state| B B -->|callback| A A -->|code + redirect_uri + code_verifier\nclient authentication when configured| M M -->|ID token + access token\nrefresh token when permitted| A A -->|access token / DPoP proof when bound| R R -->|protected resource| A A -. validates issuer, audience, signature, nonce .-> M R -. enforces application authorization .-> R
A successful redirect is not a successful authentication. The application must bind the callback to the original transaction and validate the returned identity before it creates a trusted local session.
PAR and DPoP remain conditional because they are activated by client/deployment policy rather than assumed globally.
Generate state, nonce, code_verifier; derive S256 code_challenge.
Register the authorization request through PAR and receive a short-lived one-time request_uri.
MemoID authenticates the account, verifies exact redirect URI, PKCE, requested scopes, application-entry policy and consent.
Reject OAuth error responses, missing or expired transaction state, or any state mismatch before token exchange.
Exchange the single-use authorization code with the exact redirect_uri, original code_verifier, and configured client authentication.
Validate approved JWT algorithm, signature/JWKS, iss, aud, exp and nonce; use stable sub as the identity key.
Create the application's own Secure/HttpOnly session and map application roles or tenant membership separately from MemoID entry authorization.
Send the access token and, when sender-constrained, the DPoP proof. The Resource API validates audience/context and enforces business permissions.
Use the current refresh token once, atomically persist the replacement, and treat reuse as a replay signal that can revoke the token family.
sequenceDiagram
autonumber
participant B as Browser / App
participant A as Application Backend / BFF
participant M as MemoID
participant R as Resource API
B->>A: Start sign-in
A->>A: Generate state, nonce, code_verifier
A->>A: Derive S256 code_challenge
opt PAR enabled for this client
A->>M: POST /oauth/par + authorization parameters
M-->>A: one-time request_uri
end
A-->>B: Redirect to /oauth/authorize
B->>M: Authorization request or request_uri
M->>M: Authenticate user + enforce app-entry policy
M->>M: Validate exact redirect URI, scopes, PKCE and consent
M-->>B: 303 callback?code=...&state=...
B->>A: Exact application callback
A->>A: Reject OAuth error / expired transaction / state mismatch
A->>M: POST /oauth/token + code + redirect_uri + code_verifier
M->>M: Verify single-use code and PKCE binding
M-->>A: ID token + access token + optional refresh token
A->>A: Validate signature, alg, iss, aud, exp, nonce; key identity by sub
A-->>B: Secure HttpOnly application session
opt Sender-constrained access token
A->>R: Access token + DPoP proof
else Bearer access token
A->>R: Access token
end
R->>R: Validate token/audience; enforce business authorization
R-->>A: Protected resource
opt Refresh
A->>M: Current refresh token, exactly once
M->>M: Rotate token + detect replay in token family
M-->>A: Replacement token set
endControls are documented with their operational assumptions. This avoids presenting a mechanism as effective when the connected client skips the validation it is designed to complement.
MemoID requires S256 for Authorization Code flow. A stolen code alone is insufficient without the original verifier.
Authorization responses and logout returns are restricted to registered destinations, reducing code leakage and redirect abuse.
MemoID carries OIDC transaction values, but the application must still compare state and validate nonce where used before establishing trust.
Authorization codes are not long-lived credentials. Reuse or transaction mismatch must fail rather than silently mint another token set.
MemoID publishes signing metadata and keys; the relying application is responsible for validating the returned ID token before trusting identity.
Refresh tokens are rotated on use. Replay detection can revoke the token family rather than letting a duplicated long-lived credential remain active.
Pushed Authorization Requests reduce exposure and tampering opportunities for the full authorization parameter set in the front channel.
DPoP can bind an access token to a proof-of-possession key. It is documented only for clients/resources that enable and verify it end to end.
Confidential clients may authenticate using signed JWT assertions instead of a shared Client Secret when their deployment supports key management.
MemoID returns its configured issuer in each authorization redirect. The relying party must compare it exactly with the expected issuer before exchanging a code.
These references document design intent and interoperability requirements; they are not blanket certification claims for the entire MemoID deployment.
| Area | MemoID position | Reference | Why it matters |
|---|---|---|---|
| OAuth security baseline | In use | RFC 9700 / BCP 240 | Modern OAuth threat guidance: redirect validation, PKCE, CSRF/mix-up defenses and refresh-token replay protection. |
| PKCE | In use | RFC 7636 | Binds authorization-code redemption to the original verifier. |
| OpenID identity | Shared responsibility | OpenID Connect Core 1.0 | Defines ID Token, issuer/audience/subject/nonce semantics and relying-party validation. |
| Discovery / metadata | In use | RFC 8414 · OIDC Discovery | Provides machine-readable issuer and endpoint/key metadata. |
| Native applications | Shared responsibility | RFC 8252 / BCP 212 | Defines native-app browser and redirect handling expectations. |
| PAR | Depends on configuration | RFC 9126 | Moves request registration to a protected back channel. |
| DPoP | Depends on configuration | RFC 9449 | Sender-constrains OAuth tokens using proof-of-possession. |
| JWT client auth | Depends on configuration | RFC 7523 | Supports asymmetric client authentication with signed assertions. |
| JWT validation | Shared responsibility | RFC 8725 / BCP 225 | Algorithm and claim-validation best practices. |
| Revocation / introspection | Depends on configuration | RFC 7009 · RFC 7662 | Operational lifecycle endpoints for invalidation and token-state inspection. |
| Authorization response issuer | In use | RFC 9207 | Issuer identification on authorization responses; RPs validate iss before code exchange. |
The papers below are informative background for threat modeling. Linking them here does not imply that MemoID itself has been formally verified by those authors.
Fett, Küsters and Schmitz analyze OAuth attack classes and derive security guidelines that influenced later best-current-practice work.
Formal treatment of OIDC security properties, identity assertions and web attacker assumptions useful when reviewing relying-party validation.
Useful background for stronger OAuth profiles and the security goals behind mechanisms such as PAR and sender-constrained access.
Stable anchors explain protocol terms, alternate names, MemoID-specific meaning and normative references so Security and Developer Docs can link to one definition.
Report it privately. Do not include live passwords, access tokens, refresh tokens, Client Secrets, recovery codes or MFA setup secrets in screenshots or reports.