Find plain explanations of sign-in, identity and access. Each term includes how it works in MemoID, related names and links to source specifications.
Every term has a stable hash URL. Security pages, developer docs, implementation tickets and external reviews can point to one definition instead of redefining the term in multiple places.
/dictionary#pkceA boundary where data, code or credentials move between components with different levels of control or trust.
In MemoIDMemoID separates browser-visible data, application server secrets, identity authority and destination-resource authorization into different trust zones.
The process of establishing who a user or client is.
In MemoIDMemoID authenticates users through supported sign-in methods before an authorization decision is made for an application.
The decision about what an authenticated subject is allowed to do or access.
In MemoIDMemoID decides whether an account may enter a registered application. Roles, tenant membership and resource-level permissions remain the destination application's responsibility.
A system that authenticates users and provides identity assertions to relying applications.
In MemoIDMemoID acts as the identity provider / OpenID Provider for connected applications.
The OAuth component that authorizes clients and issues access credentials after the required checks.
In MemoIDMemoID exposes authorization, token, PAR, revocation and introspection capabilities as its authorization-server surface.
An application that relies on an OpenID Provider to authenticate a user and returns to its own local authorization/session model.
In MemoIDA MemoID-connected application is an RP and must validate the ID Token and callback transaction before creating a trusted application session.
Software registered with an authorization server to request authorization on behalf of a user or itself, depending on the grant.
In MemoIDMemoID registers clients with a Client ID, type, redirect URIs, scopes and access policy.
A client that cannot reliably keep a long-lived secret confidential from the user or runtime environment.
In MemoIDPublic MemoID clients must not depend on a Client Secret and use PKCE for Authorization Code flow.
A client able to protect authentication credentials in a controlled server-side environment.
In MemoIDMemoID confidential clients may use a Client Secret or configured asymmetric client authentication such as private_key_jwt.
A public identifier assigned to a registered OAuth client. It is not a password.
In MemoIDMemoID uses Client ID to resolve the registered application configuration and policy.
A shared secret used by some confidential clients to authenticate to an authorization server.
In MemoIDIt must stay server-side and must never be placed in browser JavaScript, public repositories, mobile bundles, screenshots or support messages.
The pre-registered destination to which the authorization server sends the authorization response.
In MemoIDMemoID matches redirect URIs exactly. The callback itself must not become an open redirect.
A short-lived, single-use credential returned through the authorization response and exchanged for tokens by the client.
In MemoIDMemoID binds the code to the client, exact redirect and PKCE transaction. It is not an access token.
Proof Key for Code Exchange binds authorization-code redemption to a secret verifier generated by the client for that transaction.
In MemoIDMemoID requires the S256 method for Authorization Code flow. The verifier must be random, private until exchange and never reused.
A high-entropy per-transaction value used by the client to bind the callback to the authorization request and help prevent request substitution/CSRF-style attacks.
In MemoIDThe connected application must store state safely and reject any mismatch before token exchange.
A value sent in the authentication request and returned inside the ID Token to bind that token to the originating OIDC transaction.
In MemoIDWhen used or required by policy, the relying application must compare the ID Token nonce before trusting the login.
A string that describes the access or identity information a client is requesting.
In MemoIDMemoID commonly uses openid, profile, email and offline_access. Clients should request only what the product needs.
The user's informed approval for a client to receive requested identity/access scopes, when the flow requires it.
In MemoIDMemoID records application consent separately from the destination application's internal permissions.
A signed OpenID Connect token containing claims about the authentication event and subject for the relying party.
In MemoIDThe application must validate signature, approved algorithm, issuer, audience, expiry and nonce where applicable before using sub as the stable identity key.
A credential presented to a Resource Server to access protected APIs within its intended audience/scope/context.
In MemoIDAccess tokens are not user passwords. They should be short-lived and handled as secrets; Resource APIs must validate the expected audience and authorization context.
A sensitive credential used to obtain replacement access credentials without repeating an interactive sign-in.
In MemoIDMemoID rotates refresh tokens on use and can detect reuse within a token family. Applications must persist the replacement atomically and never expose refresh tokens to browser logs or URLs.
The identifier of the authority that issued an identity/security token.
In MemoIDApplications must compare the token issuer against the expected MemoID issuer rather than trusting whatever issuer appears in a returned token.
The stable subject identifier used by the issuer to identify the authenticated entity for the relying party.
In MemoIDUse sub as the canonical MemoID identity key. Do not use email as the permanent database identity because email can change.
The intended recipient or resource context for a token.
In MemoIDA client or Resource Server must reject a token whose audience does not match the component that is expected to consume it.
A JSON Web Key Set publishes public keys that relying systems can use to verify signatures from an issuer.
In MemoIDMemoID publishes JWKS. Clients must still enforce the expected issuer/algorithm/claims and handle key rotation without accepting arbitrary keys.
Server-managed state that represents an authenticated interaction over time. MemoID SSO sessions and destination-application sessions are separate trust domains.
In MemoIDSigning out of one application session does not automatically mean every MemoID or other application session is gone unless the logout flow explicitly revokes them.
A model where one authenticated identity session can reduce repeated sign-ins across multiple trusted applications.
In MemoIDMemoID provides SSO at the identity layer while each connected application still creates and manages its own local session and business permissions.
A mechanism that lets a client register authorization parameters directly with the authorization server and then use a short-lived request_uri in the browser.
In MemoIDMemoID documents PAR as conditional per client/deployment policy rather than assuming it is enabled globally.
A proof-of-possession mechanism that can bind OAuth tokens to a client-held key and require a fresh proof for HTTP requests.
In MemoIDDPoP is only effective when both token issuance and Resource Server validation enforce the key binding and replay protections end to end.
A client-authentication method where a confidential client signs a short-lived JWT assertion with its private key.
In MemoIDMemoID treats this as a conditional client-authentication option where key management is available; the private key must remain under the client's protected control.
An operation that invalidates a token or the authorization represented by it before natural expiry.
In MemoIDMemoID can revoke long-lived access such as refresh credentials instead of waiting for expiry when a user disconnects an app or security response requires it.
A protected server-to-server operation for asking the authorization server about token state and metadata.
In MemoIDUse introspection only from authorized server-side components. It is not a substitute for all local validation rules.
A phishing-resistant sign-in credential based on public-key cryptography and WebAuthn, often unlocked with device biometrics or a device PIN.
In MemoIDThe authenticator performs biometric verification locally; MemoID receives the cryptographic authentication result, not the raw biometric template.
A W3C API and data model for strong public-key authentication using authenticators such as platform biometrics or security keys.
In MemoIDMemoID uses WebAuthn semantics for passkey registration and authentication.
Authentication that requires evidence from more than one factor category or an additional verification step according to policy.
In MemoIDMemoID can use TOTP as an additional factor for local-password sign-in. Passkeys are a separate phishing-resistant sign-in method and should not be described as equivalent to every MFA configuration.
A one-time password derived from a shared secret and the current time window.
In MemoIDMemoID supports authenticator-app TOTP for MFA. The setup secret and recovery codes must be protected like credentials.
A high-value fallback credential used when a normal second factor is unavailable.
In MemoIDTreat recovery codes as secrets. Regenerating a set should invalidate the previous set so old screenshots or printouts cannot continue to work.
An OIDC claim describing authentication methods used for the session or authentication event, such as password or MFA-related methods.
In MemoIDMemoID may surface AMR in technical session/security details. Applications should interpret it according to their own assurance policy rather than infer privileges from a label alone.
An OIDC claim identifying the authentication context or assurance class that applied to an authentication event.
In MemoIDAn application should only rely on ACR values it understands and has explicitly mapped to policy.
A durable record of security-sensitive or administrative actions designed to support traceability and review.
In MemoIDMemoID records security/audit events while avoiding raw passwords, authorization codes, Client Secrets, refresh tokens and session tokens in logs.
An event relevant to account or system security, such as a sign-in, session change, credential change or suspicious access signal.
In MemoIDMemoID surfaces relevant user security activity and can attach technical context such as time, IP, User-Agent, method and application identifiers.
A security event enriched or classified with a risk severity that indicates it deserves additional review or response.
In MemoIDA strange network/device value is not automatically an attack: VPNs, mobile carriers, browser changes and shared IPs can create legitimate variation, so context matters.