Decoding Auth Acronyms: SAML, OIDC, SCIM, JWT & More Explained | PropelAuth

THE PERIODIC TABLE OF AUTH · 31 ELEMENTS
Explore common authentication and authorization terms, what they mean, and how they work together in your application. Where PropelAuth supports a term, a short note links to the docs.
Last updated October 16, 2026
The two jobs every other term on this page serves, and the names for the field that does them.
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.
How one login at a central identity provider turns into access across many applications.
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