Consent – Discover CIAM

Downstream IdP

In a CIAM context, the Downstream IdP can be thought of as the Identity Provider closest to the application — ultimately responsible for validating first-factor authentication from any upstream IdP and optionally applying any additional multi-factor processing. In a workflow that leverages SAML, or OIDC via Authorization Code Flow, for example, a chain of IdP interactions can exist, where the IdP furthest from the application is typically referred to as the furthest upstream IdP, and where the flow progresses downstream until the IdP nearest to the application is reached. Ultimately, the IdP nearest to the application — the furthest downstream IdP — is responsible for issuing the security token (i.e. the ID Token or SAML Assertion) consumed by the application.

Model Context Protocol

The Model Context Protocol (MCP) is an open standard that allows Large Language Models (LLMs) to integrate with and access external tools, data, and services. Developed by Anthropic, it acts like a standardised communication layer, similar to an API, enabling AI agents to perform actions, retrieve up-to-date information, and handle tasks more autonomously. Essentially, MCP provides AI systems with a way to “call” external resources to get information needed to complete a request.

Learn more about the MCP protocol @ modelcontextprotocol.io

First Party Application

In a customer identity context, a first-party application is the term typically given to software developed by a company or individual that is also the developer of the associated resource server API(s). Such applications will often access resources that are personal to a user (i.e. user information, data, documents, etc.), using an implied OAuth 2 Consent mechanism, typically supported by most (SaaS) CIAM solution providers.

Learn more about OAuth 2 Consent here

Third Party Application

In a customer identity context, a third-party application is the term typically given to software developed by a company or individual that is external to the developer of a resource server API. Such applications can offer helpful features/functionality, but as they typically access resources that are personal to a user (i.e. user information, data, documents, etc.), they can also pose security risks if not managed properly. To help combat this, OAuth 2 provides the Consent mechanism, which allows users to grant third-party applications explicit access to their resource information.

Learn more about OAuth 2 Consent here

Refresh Token

Video courtesy of Auth0 by Okta

A Refresh Token is a security artefact supported by both the Open Authorization 2.0 — a.k.a OAuth 2.0 — and OpenID Connect (OIDC) protocols, and can be generated to obtain a new instance of the token(s) with which it is associated, typically when the current token(s) become invalid or expired. A Refresh Token can be used to obtain additional Access Tokens with identical or narrower scope (i.e. Access tokens that have a shorter lifetime and lesser consent than originally authorised by the resource owner), and also ID Tokens in a similar fashion. Unlike an ID Token, and typically an Access Token, too, a Refresh Token is not usually expressed in JWT format. Support for Refresh Tokens is optional and at the discretion of the authorising service (as in the Identity Provider or Authorization Server being utilised).

Read more about OAuth 2.0, OIDC and the role of Tokens in the article: Discover/CIAM/OIDC, SAML and OAuth 2.0.

Principle of Least Privilege

In the context of information security, the term Principle of Least Privilege essentially means giving any user or process only those privileges that are vital to perform the intended function. For example, a user account created for the sole purpose of performing data backup does not need to install software; hence, it is only assigned rights to run backup and backup-related applications.

Learn more about the Principle of Least Privilege in the CyberArk article here

Authorization Code Flow

Image provided courtesy of Cloudentity, showing additional use of PKCE

Authorization Code Flow — a.k.a. the OAuth 2 Authorization Code Grant — refers is the name given to the workflow typically used in both the OIDC protocol (to obtain an ID Token) and in the OAuth 2.0 protocol to obtain an Access Token. Its use is a recommended best practice, at least for web applications and SPAs, and the way it works is illustrated in the diagram above.

For more information, see the full specification at: OpenID Connect Core 1.0

CAPTCHA

The Completely Automated Public Turing test to tell Computers and Humans Apart — or CAPTCHA, for short — is often used to differentiate between human users and automated bots. CAPTCHA challenges, such as identifying distorted text or images, make it much harder for automated scripts to execute mass login attempts.

TLS

TLS — a.k.a. Transport Layer Security, otherwise referred to as SSL (Secure Sockets Layer) — refers to a protocol for encrypting, securing, and authenticating any communication that takes place on the Internet. The main use case for TLS is securing communications between a client and a server, but it can also secure email, VoIP, and other communications over unsecured network channels.

Learn more about TLS in the article provided by Cloudflare here

Upstream IdP

In a CIAM context, an Upstream IdP can be thought of as the Identity Provider, which is ultimately responsible for validating user first-factor credentials — either interactively or via some SSO mechanism. In a workflow that leverages SAML, or OIDC via Authorization Code Flow, for example, a chain of IdP interactions can exist, where the IdP furthest from the application is typically referred to as the furthest upstream, and where the flow progresses downstream until the IdP nearest to the application is reached. Ultimately, the IdP nearest to the application is responsible for issuing the security token — i.e. the ID Token or SAML Assertion — consumed by the application.

SDK

A Software Development Kit (SDK) is a collection of tools, libraries, and resources that help developers create software for specific platforms or services. It essentially provides pre-built components, instructions, and documentation of a specific nature to help streamline the application development process.

IAM

Video courtesy of Auth0 by Okta

IAM, shorthand for Identity and Access Management, focuses on software application identities and the access-control/management associated with them. Whilst IAM typically refers to enterprise-class (user) identity and access management, CIAM is the term given to the branch that deals specifically with Customer identities typically associated with B2C and B2B SaaS applications.

Find out more about the various aspects of CIAM by visiting Discover/CIAM.

SaaS

Software-As-A-Service — more commonly known as SaaS — is a software delivery and licensing method in which software is accessed online via subscription, rather than bought and installed on individual computers. SaaS solutions commonly come in two forms, namely B2C and B2B, representing the consumer audience to which they are targeted. Derivative cases such as B2B2C, B2B2B, and B2C <-> B2B hybrids are also not uncommon.

Discover more about SaaS CIAM in the article entitled: B2C and B2B SaaS Authentication Architectures

PII

Personally Identifiable Information, otherwise known as PII, refers to any data that can be used to identify or contact a specific individual, either alone or in combination with other data. What does and does not constitute PII is largely defined by the regulatory compliance (such as GDPR) active in a particular country/region, and subject to the statutes defined therein. However, in most cases, things like Full Name, Email and Postal Address, Social Security Number and Phone Number are all considered PII data for a user.

API

An API, otherwise known as an Application Program Interface, refers to backend implementation allowing systems to communicate in a consistent manner over an HTTP interface. The term Resource Server is often used to refer to an API used to provide access to (protected) resources associated with a user, and the term API-First Design is often used to refer to software architectural design that centres around the API.

BFF

A Backend-for-Frontend, otherwise referred to as a BFF, is a pattern whereby a dedicated backend is explicitly created for a specific set of frontend functionality — typically associated with security-sensitive, critical operations. BFFs are normally used with SPA and/or Mobile/Desktop Apps, however, they can easily be utilized in other situations too.

Backend

A Backend — also referred to as an Application Backend, Backend Server, or just Server — provides a secure confidential client context in which application software can execute. Backends come in various shapes and sizes (such as web servers, database servers, etc), all with the common attribute that they are protected from direct user access and typically implemented with the highest level of trust.

Desktop App

Desktop Apps, a.k.a. Desktop Applications, run natively on platforms such as Windows, MacOS and Linux. They incorporate command-line and/or graphical user interfaces (a.k.a. GUIs) and are public clients built using native platform languages and technologies. Like Mobile Apps, Desktop Applications can optionally leverage web technologies and frameworks — both natively and within an (embedded) browser context — and similarly, BFFs or APIs are used for user-oriented data access/management, et al.

Mobile App

Mobile Apps run natively on platforms such as Android or Apple (i.e. iOS, WatchOS, VisionOS, etc). They are public clients typically built using native platform languages such as Swift, Kotlin, or Java, and can also leverage web technologies and frameworks — such as React — both natively and within an (embedded) browser context. Mobile Apps typically use BFFs or APIs for user-oriented data access and management, and can also have specific UI challenges that require less conventional methods for Authentication and Authorization.

Web Application

A Web Application, also known as a Web App, Website, or regular web application, is confidential client software created using web-oriented technologies and commonly distributed via a web server. Web applications typically comprise a user-oriented web front-end together with a corresponding web backend. Whilst similar in appearance to a SPA (Single Page Application), a regular web application and a SPA differ from a client confidentiality perspective, primarily due to the fact that the former leverages a web server backend while the latter typically does not.

SPA

A Single-Page Application, commonly referred to as a SPA, is a public client web application that interacts with a user by dynamically rewriting a single web page. Unlike regular web applications, SPAs don’t have a dedicated web backend typically leveraging resources statically and/or dynamically using a BFF or an API.

Service

A service is a typically automated operation performed by a machine rather than a user. Service identity is used to determine the right level of access, ensuring that data is only made available to trusted parties that are authorized to use it.

User

A user represents the consumer of a (SaaS) application and is the lifeblood of the commercial success of any B2C or B2B SaaS application. User identity ensures that the right access is provided to the right person at the right place and time, as well as used to describe habits, preferences and how they subscribe.

API Angel

The API Angel designs, builds and/or maintains the first-party APIs at the heart of modern Software-as-a-Service (SaaS) solution architecture, and needs the best way to protect these when accessed by either third-party and/or first-party applications.

Service Supremo

The Service Supremo, designs, builds and/or maintains backend services that don’t require user interaction but that do need to safely and securely communicate with other services and (first-party) APIs.

IoT Icon

An IoT (Internet of Things) Icon, designs, builds and/or maintains embedded code that runs as part of IoT devices — that need to access first-party APIs either on behalf of a user or without any user interaction at all.

Device-bound Passkeys

Video courtesy of Auth0 by Okta

A device-bound passkey is a FIDO2 credential that is typically stored on physical security keys or hardware modules and is tied to a single device — meaning it cannot be copied or shared across multiple devices.

Discoverable Credentials

Video courtesy of Auth0 by Okta

A discoverable credential is a type of FIDO2/WebAuthn credential that allows users to log in without needing to enter either a username or a password, as sufficient user credential information is stored on the authenticator (e.g., security key, device or browser).

Man In The Middle

Image courtesy of InfosecTrain; click to read more on Medium

A Man In The Middle — also referred to as MITM — is a type of cyber attack, where an attacker intercepts and potentially alters communications between two legitimate parties, making them believe they are communicating directly with each other (when actually they are communicating with an illegitimate system).

ReBAC

Relationship-Based Access Control — more commonly referred to as ReBAC — is a method of control that restricts access based on the particular relationships established between one or more users and/or other entities. ReBAC can be used in conjunction with other methodologies, such as RBAC or ABAC, to create rich access control strategies.

Discover more about ReBAC in the article entitled: Access In A Controlled Manner

OTP

Video courtesy of Auth0 by Okta

OTP stands for One-Time Password/Passcode and is commonly used as a passwordless authentication mechanism where a (password) security credential is valid for a single use. An OTP is similar to an OTC — a One-Time Code — and an OTL, a.k.a. One-Time (Magic) Link, in that each is only valid for one-time use. OTPs, OTCs and OTLs also come in timed varieties, i.e. TOTPs, TOTCs and TOTLs, where the password, code and/or (magic) link is also only valid for a certain duration.

Discover more about OTPs, OTCs and OTLs in the article entitled: Passwordless OTP and Magic Link Scenarios.

Step-Up Authentication

Step-up Authentication is a security measure where users are prompted to reauthenticate with a higher assurance level — e.g. using Multi-Factor Authentication credentials — when accessing sensitive resources or performing high-risk actions, providing enhanced security beyond that afforded by standard authentication.

Account Linking

Image courtesy of SuperTokens

Account Linking refers to the process of linking one or more accounts for a given user — e.g. an account created via the use of UserID/Password credentials with one or more Social accounts, such as Facebook, Google, LinkedIn, etc. — so that the profile for the user is consistent no matter how they choose to log in.

Discover more about Account Linking in the article entitled: Why Account Linking Should Be Pivotal in your CIAM SSO

First Factor

In terms of Authentication, the term First Factor — often synonymous with the Login process — refers to the credentials a user presents that are typically used to initially identify that user.

To learn more about first-factor credentials and the Login process visit Discover/CIAM/Login.

Delegation

In the context of Customer Identity and Access Management (CIAM), delegation refers to the ability to empower (business) partners or sub-organizations when it comes to managing their own users and access to services while maintaining administrative ownership overall, especially from a control and security perspective.

Delegated Authorization

Video courtesy of Auth0 by Okta

In OAuth 2.0, Delegated Authorization allows a user to grant a (third-party) client — e.g. an application — access to their protected resources on a resource server, enabling the client to act on the user’s behalf without the user needing to reveal their credentials.

Read more about delegated authorization and the value it provides at: Discover/CIAM/Consent

Client Credentials

Client Credentials is the term used to refer to the credentials associated with a client — i.e. any non-user entity, such as automated system service. Client Credentials are typically associated with the OAuth 2.0 Client Credentials Grant type, used to obtain an OAuth 2.0 Access Token outside the context of a user. In the Client Credentials Grant flow, the obtained OAuth 2.0 Access Token can be used to access services/resources at a machine-level context rather than on behalf of a user.

FIDO

Video courtesy of Auth0 by Okta

The FIDO (Fast IDentity Online) Alliance is an open industry association with a mission focused on reducing the world’s reliance on passwords. To accomplish this, FIDO promotes the development of, use of, and compliance with standards — e.g. FIDO2 — for authentication and device attestation.

JWT

Video courtesy of Auth0 by Okta

A JSON Web Token — otherwise known as a JWT (pronounced “JOT”) — is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties in the form of a JSON object.

PKCE

Video courtesy of Auth0 by Okta

PKCE, or Proof Key for Code Exchange, is an Authorization Code grant/flow extension designed to mitigate authorization code interception attacks and is particularly intended for use with public clients (i.e. Mobile Apps, Single Page Applications, etc).

See the full specification at: IETF/RFC/7636

Passkeys

Video courtesy of Auth0 by Okta

By replacing traditional passwords with cryptographic keys, Passkeys — a discoverable WebAuthn credential — address many of the vulnerabilities that’ve plagued password-based systems for years, ushering in a new future for user authentication.

Find out more about Passkeys at: Discover/CIAM/Passkeys.

WebAuthn

Video courtesy of Auth0 by Okta

The Web Authentication API (also known as WebAuthn) specification — written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others — allows servers to register and authenticate users using public key cryptography instead of passwords.

Find out more about WebAuthn at: WebAuthn.Guide.

Bad Actor

The term “Bad Actor” (a.k.a. “Threat Actor” or “Malicious Actor”) is often associated with a person, group, country, etc. that purposely, and often repeatedly, engages in bad behaviour — such as causing trouble, committing crimes or doing harm to digital systems and the like.

Service Provider

Service Provider is the term used in SAML for a (B2B) SaaS application requiring User Authentication. The term Service Provider is semantically equivalent to the term Relying Party which is used in the OAuth 2.0 and OIDC protocol specifications.

Role Based Access Control

Role Based Access Control — known more commonly as RBAC — is a method of control that restricts access based on the particular role(s) assigned to a user. RBAC can be used in conjunction with other methodologies, such as ReBAC or ABAC, to create rich access control strategies.

Discover more about RBAC in the article entitled: Access In A Controlled Manner

Login

Login — a.k.a. Sign-in — is the most commonly recognised mechanism for identifying a user to your application, and typically uses a process of interactive authentication initiated via a user interface referred to as the Login Box. Login will often support multiple first-factor authentication mechanisms such as UserID & Password, Social and/or (Enterprise) Federation, as well as SSO.

Learn more about Login at: Discover/CIAM/Login

Access Token

Video courtesy of Auth0 by Okta

An Access Token is a security artefact generated when using the Open Authorization 2.0 (a.k.a OAuth 2.0) protocol and is used to allow consented access to a user’s resources. The token is used (though not consumed) by an application when calling a resource server — otherwise referred to as an API — which, in turn, consumes the token provided to determine if the application has been granted access on behalf of the authenticated user.

Read more about OAuth 2.0 and the role of the Access Token in the article: Discover/CIAM/OIDC, SAML and OAuth 2.0.

ID Token

Video courtesy of Auth0 by Okta

An ID Token is a JWT format security artefact generated when using the Open ID Connect (a.k.a OIDC) protocol and is used to indicate the authentication state of a user. The token is consumed by an application and used to build the authenticated user session as well as inform (basic) characteristics about the authenticated user.

Read more about OIDC and the role of the ID Token read the article: Discover/CIAM/OIDC, SAML and OAuth 2.0.

B2C

B2C – better known as Business-to-Consumer – refers to the process of businesses selling products and services directly to customers, bypassing any third-party retailers, wholesalers, or other middle ground. In commercial terms, B2C typically refers to retailers who sell products and services to consumers directly via online mechanisms, also known as Software-as-a-Service (or SaaS for short).

Discover more in the B2C and B2B SaaS Authentication Architectures article

CIAM

Video courtesy of Auth0 by Okta

Customer Identity and Access Management, abbreviated as CIAM, is a form of IAM that focuses on the consumer identities that access applications.

Find out all about CIAM by visiting Discover/CIAM.

User Authentication

User Authentication is the process of identifying a user to your application and is typically achieved via the interactive Login process with which we’re all familiar.

You can discover more about User Authentication, at: Discover/CIAM/Login

Authentication

Video courtesy of Auth0 by Okta

Authentication is the process of identifying access to a system to secure functionality and is almost always the prerequisite for any other type of CIAM operation.

More information about Authentication is available at Discover/CIAM/Authenticate.

Web backend

A Web backend — also referred to as a Web Server — is a server-side, confidential client implementation, typically using a language such as PHP, Ruby, Python, C#, or the like, and typically in conjunction with an associated web framework such as Laravel, Rails, Flask, .NET, etc. A Web backend will normally leverage an explicit Web Server technology, such as Apache, nginx or IIS, which is specifically designed to handle web-oriented communications (such as HTTP, FTP, or similar).

Web front-end

A browser-based implementation using HTML, CSS and Javascript, optionally via frameworks such as React, Angular and/or Vue.

Desktop Discoverer

The Desktop Discoverer designs, builds and/or maintains Desktop Apps – supporting user interaction via a GUI and/or Command Line interface – leveraging native functionality, and optionally web-based integration, to provide user experiences that typically consume (first-party) APIs and/or BFF implementations.

Mobile Maestro

A Mobile Maestro designs, builds and/or maintains Mobile Apps, leveraging native platform functionality and (optionally) web-based integration, to provide user experiences that typically consume (first-party) APIs and/or BFF implementations.

Web Warrior

A Web Warrior is someone who designs, builds and/or maintains web-based applications that run either wholly in the browser – a.k.a. a SPA – or via a combination of both browser and backend technologies (also referred to as a Web App or Regular Web Application).

Public Client

A Public Client is an OIDC/OAuth 2.0 client application type that cannot store highly sensitive security information – such as the Client Secret – in a manner that’s not publicly accessible. Examples of Public Clients include SPAs and Mobile applications where, despite technology advances such as the Secure Enclave and the Trusted Execution Environment, implementing measures to mitigate security risks and protect user data is typically more complex.

Confidential Client

A Confidential Client is an OIDC/OAuth 2.0 client application type that allows highly sensitive security information – such as the Client Secret – to be stored in a manner that is not publicly accessible. A regular web application is an example of a Confidential Client.

Social Authentication

Social Authentication — a.k.a Social Login — allows the use of identity providers such as Google, Microsoft, Facebook, LinkedIn, X, etc to authenticate users, whilst also providing consented access to the profile information they store about that user.

Read more about social authentication and the value it provides at: Discover/CIAM/Social

SAML

Video courtesy of Auth0 by Okta

SAML is an acronym that stands for Security Assertion Markup Language and is an open standard developed primarily for authentication within an enterprise environment. SAML is based upon the Extensible Markup Language (XML) format and delivers functionality, via established trust, that enables a user to access multiple applications using one set of login credentials (more commonly referred to as SSO).

You can learn more about SAML at: Discover/CIAM/Federation

OAuth 2.0

OAuth 2.0 stands for Open Authorization (version 2.0) and is a standard designed to allow a website or application to access resources hosted by other web-based systems, on behalf of a user. It leverages the concept of an Authorization Server and replaced OAuth 1.0 in 2012 to become the de facto industry standard for what is often referred to as delegated authorization.

You can learn more about OAuth 2.0, and the role of an Authorization Server, in the article entitled: OIDC, SAML and OAuth 2.0

MFA

Video courtesy of Auth0 by Okta

Otherwise referred to as Multi-Factor Authentication or Two-Factor Authentication, MFA (a.k.a. 2FA) is where additional factors — such as an electronic device and/or biometric method — are used in conjunction with a more traditional first-factor authentication mechanism, e.g. User ID and Password. In MFA scenarios, only after successfully presenting two or more pieces of evidence — a.k.a. factors — would the requisite level of authentication be achieved.

Find out more about MFA at Discover/CIAM/MFA.

B2B

B2B – better known as Business-to-Business – refers to the process of businesses selling products and services directly to other businesses rather than selling directly to consumers. In commercial terms, B2B typically refers to organisations that leverage the online products and/or services provided by other organisations, often referred to as Software-as-a-Service or SaaS for short.

Discover more in the B2C and B2B SaaS Authentication Architectures article

Identity Provider

Video courtesy of Auth0 by Okta

For security protocols like Open ID Connect (otherwise known as OIDC) and SAML, an Identity Provider – a.k.a. an IdP – is typically a web-based server/service that performs the role of verifying user credentials and, optionally, establishing and maintaining the SSO session for a user.

You can learn more about OIDC, SAML, and the value of SSO, at: Discover/CIAM/OIDC, SAML and OAuth 2.0.

OpenID Connect

Developed by the OpenID Foundation, OpenID Connect – a.k.a. OIDC – is an interoperable authentication protocol based on the OAuth 2.0 framework of specifications (namely, IETF RFC 6749 and 6750). It provides a simplified way to verify the identity of users based on the authentication performed by an Identity Provider (otherwise known as an IdP) and allows user profile information to be obtained in an interoperable and REST-like manner.

You can learn more about OpenID Connect, and the role of an Identity Provider, in the article at: Discover/CIAM/OIDC, SAML and OAuth 2.0

GDPR

GDPR – also known as the General Data Protection Regulation – is a privacy and security law, and arguably one of the toughest in the world. Though it was drafted and passed by the European Union (EU), it imposes obligations onto organizations anywhere that target or collect data related to people in the EU. The regulation was put into effect on May 25, 2018, and will levy harsh fines against those who violate its privacy and security standards, with penalties that can reach tens of millions of euros.

You can find out more about GDPR at https://gdpr.eu/what-is-gdpr

SSO

SSO is short for Single Sign On — a term typically used for the mechanism where an existing authenticated user session can be used to mitigate interactive first-factor authentication (a.k.a interactive Login). SSO can also refer to situations where a user has more than one identity, and not only provides ease of use but also facilitates consistency when it comes to user profile management.

Read more about SSO and the value it provides at: Discover/CIAM/SSO

Peter Fernandez

As an Innovator, Architect, Advocate, Consultant, Engineer and CIAM specialist, I have over 30 years of experience designing and developing secure and robust software solutions. When I’m not helping folks with the complexities of Customer Identity, you can usually find me involved in the world of Theatre, working behind the scenes, acting in or directing a show at a local venue.

Follow me and learn more about Customer Identity at: Discover/CIAM

Tag: Consent

Auth In The World Of Customer Identity

Accessing Resources By Consent

Access Control And Consent Convergence