Decoding Auth Acronyms: SAML, OIDC, SCIM, JWT, RBAC and 26 more, explained

Authentication (AuthN) is the process of checking that someone signing in is who they claim to be, using a password, passkey, one-time code or other proof.

Authentication (AuthN) verifies the identity of a user, service or device. A login form might check a password; other methods use a magic link, one-time code, token or hardware security key. The application checks that proof before accepting the claimed identity. AuthN appears alongside AuthZ in architecture diagrams and library names because authentication and authorization answer different questions: knowing who someone is does not establish what they may do.

Often confused with:AuthZ

In PropelAuth: PropelAuth handles authentication with hosted login pages that support passwords, magic links, social login and enterprise SSO. Login methods docs.

Authorization (AuthZ) is the process of deciding what a signed-in person or service is allowed to see or do in your application.

Authorization (AuthZ) controls access to resources and actions. For example, a Member might read a document while only an Admin can change billing for that organization. Roles, permissions, policies and access control lists are all authorization tools. These checks can apply to users, services and anonymous callers: a policy might allow anyone to read a public page. Authentication establishes identity; your application still needs to check permission for each protected action.

Often confused with:AuthNRBAC

In PropelAuth: PropelAuth models authorization as roles and permissions scoped to each organization, checked in the backend libraries. Roles and permissions docs.

CIAM (Customer Identity and Access Management) is identity and access management for your customers rather than your employees: how they sign up, log in and reach what they are allowed to use.

Customer Identity and Access Management (CIAM) serves external users, while Workforce IAM focuses on employees. It covers self-service signup, login UX, password reset flows and account management as a product scales. Customers may sign themselves up, accept an invitation or have an administrator provision their account. B2B CIAM adds organizations, member roles and per-customer enterprise login settings, so each business can manage its own people and access requirements.

In PropelAuth: PropelAuth is CIAM for B2B products, with organizations, invitations and enterprise SSO configured per customer. Organizations docs.

SSO (Single Sign-On) is a login arrangement in which a person signs in once with a central identity provider and can then use several applications without signing in again.

Single Sign-On (SSO) uses a central identity provider, with protocols such as SAML or OpenID Connect (OIDC) carrying the login result to each application. An employee who signs in through Okta can then open connected apps without entering credentials again, subject to sign-in policies. Social login with Google can provide SSO too. Enterprise customers use it to manage sign-in centrally; ending existing application sessions also depends on each app's session and deprovisioning controls.

Often confused with:SAMLOIDCIdP

In PropelAuth: Customers configure SAML or OIDC single sign-on for their own organization from the hosted admin UI. Enterprise SSO docs.

SAML (Security Assertion Markup Language) is an XML-based standard, SAML 2.0 from OASIS, that lets your application trust a customer's company login instead of asking for another password.

Security Assertion Markup Language is an XML-based open standard for exchanging authentication and authorization data. SAML 2.0 (OASIS, 2005) is widely used for enterprise SSO. The identity provider (IdP) sends the service provider (SP) a signed XML assertion identifying the user and supplying attributes. The app checks the signature against the IdP's certificate, validates details such as the intended recipient and expiry, then creates a session. Many enterprise identity providers support SAML, so it is a common requirement from customer IT teams.

Often confused with:SSOOIDCIdP

In PropelAuth: PropelAuth acts as the SAML service provider and lets each customer connect their own identity provider. SAML docs.

An IdP (Identity Provider) is the system that checks who a user is, such as Okta or Microsoft Entra ID, and tells connected applications that they have signed in.

An Identity Provider (IdP), such as Okta, Microsoft Entra ID or Google Workspace, manages user identities and authentication. It can enforce MFA and application access policies across many apps. During federated login, your application receives a SAML assertion or OIDC token instead of the user's password. For passkeys, the IdP checks a signature using a registered public key; the private key stays with the authenticator or credential provider. The IdP handles sign-in, while each application enforces its own resource permissions.

Often confused with:SPSSO

In PropelAuth: PropelAuth connects to any SAML or OIDC identity provider, including Okta, Entra ID, Google Workspace, JumpCloud and Ping Identity. Enterprise SSO docs.

An SP (Service Provider) is the application someone wants to use after signing in with their identity provider; in SAML terms, your app is the SP.

In SAML, the Service Provider (SP) trusts an identity provider to authenticate users. The SP publishes metadata such as its entity ID and Assertion Consumer Service (ACS) URL; metadata can also include a certificate for signed requests. It validates the received assertion, including its signature, intended recipient and expiry, before creating an application session. OpenID Connect calls the equivalent application a Relying Party (RP), which validates ID tokens instead of SAML assertions. The app remains responsible for its own authorization checks.

Often confused with:IdP

In PropelAuth: PropelAuth is the service provider in every customer SAML connection, so you never parse XML assertions yourself. SAML docs.

OAuth 2.0 (Open Authorization 2.0, RFC 6749) is an authorization framework that lets an application access approved data or actions on another service without receiving the user's password.

OAuth 2.0 (Open Authorization 2.0, RFC 6749) is an authorization framework behind flows such as “Connect your Google Calendar”. An authorization server issues an access token, and the app uses it to call an API within its scopes. Access can be on a user's behalf or, through client credentials, as the application itself. Tokens may contain identity information, but OAuth 2.0 alone does not standardize a login result. OpenID Connect adds authentication; OAuth 2.1 consolidates security best practices.

Often confused with:OIDCOAuth 2.1PKCE

In PropelAuth: PropelAuth can act as an OAuth 2.0 and OAuth 2.1 authorization server for your own APIs and MCP servers. MCP authentication docs.

OIDC (OpenID Connect) is an identity protocol built on OAuth 2.0 that lets your app verify who signed in through another service, such as Google, using a signed ID token.

OIDC adds an identity layer to OAuth 2.0, defined in OpenID Connect Core 1.0. It supplies a signed ID token (a JWT) and a standard UserInfo endpoint. Your app validates the token with the provider's keys and checks claims such as issuer, audience and expiry. Email, authentication time and authentication method depend on the request and provider. Used for enterprise SSO and “Sign in with Google”, OIDC uses JSON over HTTPS rather than SAML's XML. The ID token identifies the signed-in user; an access token authorizes API access.

Often confused with:OAuth 2.0SAMLJWT

In PropelAuth: Customers can connect an OIDC identity provider for enterprise SSO alongside or instead of SAML. Enterprise SSO docs.

PKCE (Proof Key for Code Exchange, RFC 7636) is an extension to the OAuth 2.0 login flow that stops a stolen sign-in code from being exchanged for tokens by anyone but the app that started the flow.

Proof Key for Code Exchange (PKCE, pronounced “pixie”) extends the OAuth 2.0 authorization code flow under RFC 7636. The client creates a random code verifier and sends its hash as the code_challenge. To redeem the authorization code, it must send the original verifier too. Someone who steals only the code cannot exchange it for tokens. PKCE protects public clients such as mobile and single-page apps, and OAuth 2.1 requires it for authorization code flows with confidential clients too. It does not apply to the client credentials grant.

Often confused with:OAuth 2.0OAuth 2.1

In PropelAuth: PropelAuth requires PKCE on every authorization code flow, as OAuth 2.1 and the MCP specification demand. MCP authentication docs.

DCR (Dynamic Client Registration, RFC 7591) is an OAuth 2.0 mechanism that lets an app register itself with an authorization server instead of a developer setting it up by hand.

Dynamic Client Registration (DCR) is the OAuth 2.0 registration mechanism defined in RFC 7591. A client posts metadata, such as its name and redirect URIs, to an authorization server's registration endpoint and receives a client ID. Registration sets up the client; obtaining an access token still requires the appropriate OAuth flow. DCR can help MCP clients connect without manual setup when the server supports it. Other deployments use pre-registration or other supported client identification mechanisms, and the authorization server can apply policy to who may register.

Often confused with:OAuth 2.0MCP

In PropelAuth: PropelAuth supports dynamic client registration so MCP clients can connect to your server without manual setup. MCP authentication docs.

JIT provisioning (Just-in-Time provisioning) is a mechanism that creates a user's account in your app automatically the first time they sign in through their company's login.

Just-in-Time provisioning (JIT) creates an application account on the first successful Single Sign-On (SSO) login. The app uses identity attributes from the SAML assertion or OpenID Connect ID token, such as a name or email when supplied, instead of requiring an administrator to create the account in advance. JIT reduces manual onboarding because the identity provider already authenticates the user. It does not provide an offboarding channel: someone who leaves may never log in again. SCIM provisioning and deprovisioning can keep the account lifecycle in sync independently of login.

Often confused with:SCIMSSO

In PropelAuth: Users who sign in through a customer's SSO connection are created in that organization automatically. Enterprise SSO docs.

A JWT (JSON Web Token, RFC 7519) is a compact, signed token that carries claims about a user or service so another system can check them and act on them.

A JSON Web Token (JWT, pronounced “jot”) is a compact, URL-safe representation of claims defined in RFC 7519. A common signed JWT has three dot-separated parts: a base64url-encoded header, a payload of claims, and a signature or message authentication code. These JSON Web Signature (JWS) tokens let a recipient verify integrity with a trusted public key or shared secret, then check claims such as issuer, audience and expiry. Local verification makes JWTs popular as access tokens carrying identity and authorization information. Signed claims remain readable; JSON Web Encryption (JWE) can encrypt a JWT to keep its claims private.

Often confused with:JWKS

In PropelAuth: PropelAuth issues access tokens as JWTs that the backend libraries verify locally against your project's public key. Access tokens docs.

A JWKS (JSON Web Key Set) is a published JSON document of public keys that lets an app find the key it needs to check a token's signature.

A JSON Web Key Set (JWKS) is a JSON document containing JSON Web Keys (JWKs), defined in RFC 7517. For token verification, an issuer publishes its public keys at a JWKS endpoint; an OpenID Provider advertises this URL in its discovery document. Verifiers can fetch and cache the set, then match the kid, or key ID, in a JWT header to the appropriate key. During key rotation, publishing new and old keys together lets existing tokens remain verifiable while new tokens use the new key. The endpoint URL comes from trusted configuration or discovery, not from a universally fixed path.

Often confused with:JWTOIDC

In PropelAuth: PropelAuth exposes a JWKS endpoint for each project, which the libraries use to verify tokens and pick up rotated keys. Access tokens docs.

M2M (Machine-to-Machine) authentication is how one service proves its identity to another, with an API key or OAuth client credentials, when no person is signing in.

Machine-to-Machine (M2M) authentication gives a nightly job or microservice its own identity when calling an API. With the OAuth 2.0 client credentials grant, the service authenticates to an authorization server to obtain an access token, often using a client ID and secret. An API key usually goes directly in API requests instead of being exchanged for a token. These approaches support service-to-service access with no interactive user login. Rotate credentials and scope permissions tightly so each service can access only what it needs.

Often confused with:API keyOAuth 2.0

In PropelAuth: Organization API keys give a customer's systems a credential to call your API without a logged-in user. API key docs.

An API key is a secret string that an application sends with each request to identify itself to an API and get access.

An Application Programming Interface key (API key) is a credential issued to a client or customer, often scoped to an account or organization. The caller usually sends this random string in an HTTP header. Anyone holding a secret API key can use the access it grants, so keys need limited permissions, rotation and revocation. Mature APIs can hash keys at rest, display them only once, allow multiple keys per account, and support expiry and rate limits. B2B products often issue organization API keys for shared integrations, while a personal access token (PAT) represents an individual user.

Often confused with:M2MJWT

In PropelAuth: PropelAuth issues, validates and rate limits API keys for your users and organizations, and reports usage per key. API key docs.

SCIM (System for Cross-domain Identity Management, RFC 7643 and 7644) is a standard that keeps user accounts in your app in sync with a customer's employee directory.

System for Cross-domain Identity Management (SCIM, pronounced “skim”) is an open REST and JSON standard defined in RFC 7643 and RFC 7644. It lets an identity provider create, update and deactivate user accounts, and manage groups, in connected applications. Adding someone to an Engineering group in Okta can provision their account before their first login. When someone leaves, SCIM can automate deprovisioning through the same endpoint. SSO handles login; SCIM handles the account lifecycle. Synchronization timing and termination of existing sessions depend on the identity provider and application, so deactivation does not imply instant session revocation.

Often confused with:JITSAML

In PropelAuth: PropelAuth hosts the SCIM endpoint for each customer so their identity provider can provision and deprovision users in your product. SCIM docs.

RBAC (Role-Based Access Control) is an authorization model that gives people access based on their role, such as Admin, Member or Viewer.

Role-Based Access Control (RBAC) is an authorization model that groups permissions into named roles and assigns those roles to users. In a B2B product, an Owner or Admin might manage billing while a Member can edit projects and a Viewer can only read them. Roles are often scoped to an organization, so a person can be an Admin in one customer account and a Viewer in another. RBAC is easy to reason about when access follows a small set of responsibilities. Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC) can complement roles when access also depends on context or individual resources.

Often confused with:ABAC

In PropelAuth: PropelAuth includes RBAC with roles and permissions scoped per organization, plus role mappings from SSO groups. Roles and permissions docs.

ABAC (Attribute-Based Access Control) is an authorization model that checks details about the person, the resource and the situation to decide whether access is allowed.

Attribute-Based Access Control (ABAC) evaluates authorization policies using attributes of the user, resource, action and environment. For example, a Finance employee may approve an invoice under $10,000 during business hours. The department, invoice amount and current time all contribute to the decision; a role can also be an attribute. This supports fine-grained access control beyond roles alone. Implementations range from application code to policy engines, and complex rules can be harder to audit. ABAC does not require a particular policy language or engine. NIST SP 800-162 is the reference description.

Often confused with:RBAC

MFA (Multi-Factor Authentication) is authentication that requires two or more different kinds of proof that it is you, so a stolen password alone is not enough.

Multi-Factor Authentication (MFA) requires two or more independent factors: something you know, have or are. Two-Factor Authentication (2FA) means exactly two. A password plus a TOTP authenticator-app code is a common example; two passwords are still one factor category. SMS codes also provide a second factor, but are vulnerable to SIM swapping. MFA can be passwordless: a passkey with required local user verification by a PIN or biometric can combine possession with another factor. Enterprise customers may require MFA in your product or at their identity provider.

Often confused with:TOTPWebAuthn

In PropelAuth: PropelAuth supports authenticator-app MFA for users and lets organizations require it for all members, plus step-up MFA for sensitive actions. MFA docs.

2FA (Two-Factor Authentication) is multi-factor authentication with exactly two factors, most often a password plus a one-time code from an app or a security key.

All 2FA is MFA, but not all MFA is 2FA. The second factor is usually a six-digit code from an authenticator app, an SMS message or a hardware key. Codes from an app are safer than SMS, which can be intercepted by SIM swapping. Most consumer products say 2FA; most security questionnaires say MFA; they are asking about the same control.

Often confused with:MFA

In PropelAuth: Organizations can require 2FA for every member, and users enrol with any TOTP authenticator app. Organization 2FA docs.

TOTP (Time-based One-Time Password, RFC 6238) is a standard for short-lived login codes generated from a secret shared by your authenticator app and the server.

Time-based One-Time Password (TOTP), defined in RFC 6238, uses a shared secret and the current time to generate an OTP. Scanning a QR code into Google Authenticator or 1Password stores that secret. The app and server calculate matching codes, typically six digits that change every thirty seconds; code length and time step are configurable. The app can generate codes without a network connection, even in airplane mode. Clock drift can cause rejected codes. A TOTP code alongside a password is a common MFA or 2FA setup.

In PropelAuth: Users enrol a TOTP authenticator app for MFA from the hosted account page. MFA docs.

WebAuthn (Web Authentication API) is the W3C browser standard that lets websites use your device or security key to prove it is you, and it is what passkeys are built on.

The Web Authentication API (WebAuthn) is the W3C JavaScript API for creating and using FIDO2 public-key credentials. W3C Web Authentication Level 2 defines the browser interface. Passkeys use these credentials and may be synced or bound to one device, often unlocked with a fingerprint, face scan or device PIN. At registration, the website stores a public key. At login, the authenticator signs a challenge; the server checks that signature against the public key. The private key is not sent to the website, and credentials are bound to the relying party.

CSRF (Cross-Site Request Forgery) is an attack that tricks your browser into sending an unwanted request to a site where you are already signed in.

Cross-Site Request Forgery (CSRF) exploits the browser's ability to attach session cookies to requests triggered by another site, subject to cookie and browser rules. A malicious page might submit a form as the logged-in user. Protect state-changing requests with anti-forgery tokens and origin checks; SameSite cookies add another defense. Tokens may be scoped to a session or request. APIs that authenticate only through bearer tokens explicitly supplied in an Authorization header generally avoid classic cookie-based CSRF. CORS alone is not a CSRF defense.

Often confused with:CORS

CORS (Cross-Origin Resource Sharing) is the browser mechanism, controlled by server headers, that decides whether a website may read a response from another site.

Cross-Origin Resource Sharing (CORS) uses server response headers to relax the browser's same-origin policy. Script on app.example.com cannot normally read responses from api.example.com unless the API allows it with headers such as Access-Control-Allow-Origin. Some requests first trigger a preflight check. CORS controls browser access to cross-origin responses; it does not authenticate callers or stop direct API calls with curl. When diagnosing a CORS error, check response headers, preflight requests, client credentials settings, redirects and network failures.

Often confused with:CSRF

Credential stuffing is an attack that tries stolen username and password pairs on other sites to find reused passwords.

Attackers use bots to test credentials exposed in a data breach against other login pages. Password reuse means a pair stolen from one service may also work in your application. Credential stuffing replays known pairs rather than inventing new passwords, although it is sometimes grouped under the broader category of brute-force attacks. Rate limiting, bot detection and breached-password checks can reduce the risk. Multi-Factor Authentication (MFA) adds another barrier, while replacing password sign-in with passkeys removes the reused password from that login flow.

Often confused with:Brute ForceMFA

Brute force is an attack that tries many possible passwords until one works or the attempts are stopped.

A brute-force attack automates repeated password guesses, often starting with common passwords or dictionary words. Unlike credential stuffing, the attacker does not need a known username and password pair from another breach. Online login attacks face controls such as rate limiting; offline cracking of stolen password hashes does not. Long, unique passwords and secure password hashing make guessing harder. Breached-password checks, bot detection and Multi-Factor Authentication (MFA) add protection for password logins. Passkeys replace the shared password with a cryptographic sign-in, removing password guessing from that flow.

Often confused with:Credential StuffingMFA

SOC 2 (System and Organization Controls 2) is an AICPA auditing standard whose report shares an independent auditor's findings about how a company protects customer data.

System and Organization Controls 2 (SOC 2) is an AICPA attestation reporting framework based on the Trust Services Criteria. Security is included; availability, processing integrity, confidentiality and privacy depend on the examination's scope. Type 1 (Type I) evaluates control design at a specified date; Type 2 (Type II) also evaluates operating effectiveness over a period. Enterprise buyers use the report in vendor assessments. MFA, access reviews, offboarding and audit logs can support relevant controls. A provider's SOC 2 report does not replace your own examination, and SOC 2 is not a certification.

In PropelAuth: PropelAuth has a SOC 2 Type 2 report and is pentested annually by an independent firm. Security and compliance.

MCP (Model Context Protocol) is an open protocol that gives AI assistants a shared way to use tools and data from other applications, with an authorization layer based on OAuth 2.1.

Model Context Protocol (MCP) is an open protocol connecting AI models and agents to external tools and data sources. An MCP server can expose “list my invoices” to Claude or ChatGPT. For protected remote HTTP servers, the MCP authorization specification uses OAuth 2.1 and Protected Resource Metadata to discover authorization servers. Clients identify or register themselves using a supported mechanism, which may include dynamic client registration, then complete an OAuth flow to obtain access tokens. The server validates tokens and enforces permissions. Local stdio servers use a different credential model.

Often confused with:OAuth 2.1DCRPRM

In PropelAuth: PropelAuth acts as the authorization server for your MCP server, handling discovery, client registration, consent and token validation. MCP authentication docs.

OAuth 2.1 (Open Authorization 2.1) is a draft consolidation of OAuth 2.0 and its security best practices into one specification, bringing together safer ways for apps to get permission to access data.

Open Authorization 2.1 (OAuth 2.1), specified in the draft-ietf-oauth-v2-1 document series, consolidates OAuth 2.0 and security best practices. It requires Proof Key for Code Exchange (PKCE) for authorization code flows, tightens redirect URI matching and omits the implicit and resource owner password credentials grants. PKCE does not apply to grants such as client credentials. These protections are also available in OAuth 2.0 deployments. MCP uses OAuth 2.1 as the authorization baseline for protected remote HTTP servers.

Often confused with:OAuth 2.0PKCEMCP

In PropelAuth: PropelAuth implements the OAuth 2.1 profile MCP requires, including mandatory PKCE and resource indicators. MCP authentication docs.

PRM (Protected Resource Metadata, RFC 9728) is a discovery document that tells an app where to go to get permission to use an API.

Protected Resource Metadata (PRM), defined in RFC 9728, is a JSON discovery document published by a resource server. In MCP, a protected remote server can point to it with a WWW-Authenticate header on a 401 response. Its authorization_servers field identifies authorization servers; optional metadata can describe supported scopes and other capabilities. The client uses this information to discover an authorization server and begin the OAuth flow. Metadata can be cached, so discovery does not require a fresh unauthenticated request every time.

Often confused with:MCPOIDC

In PropelAuth: PropelAuth documents how to serve Protected Resource Metadata from your MCP server so clients can discover it. MCP authentication docs.