Customer Identity and Access Management (a.k.a CIAM) provides the tools, processes, policies and design patterns to manage and secure customer identities and control access to applications, services, and resources. CIAM ensures that only authenticated and authorized users can access restricted information and functionality, and enables self-service capability as part of a safe and seamless user…
Customer Identity and Access Management (CIAM) has become a crucial aspect of modern consumer-oriented software-as-a-service (SaaS) applications. A good CIAM architecture provides the tools, processes, policies and design patterns to manage and secure customer identities and control access to applications, services, and resources.
CIAM ensures that only authenticated and authorised users can access restricted information and functionality, and enables self-service capability as part of a safe and seamless user experience. You can read more about architecting a CIAM solution in my article:
My name’s Peter Fernandez, and in this article, I’m going to discuss what you should be looking for in a CIAM solution, along with the relative merits of Build vs Buy vs DIY (hint: almost always avoid the former, whichever of the other routes you decide to go 😎).
CIAM in a Nutshell
At first glance, creating your own simple User ID and Password implementation may seem all that’s required. We’ve all been there: create a user interface, collect credentials, and then check the credentials provided against some form of database record. However, processing User ID and Password credentials is just the tip of the iceberg, and there are several things you’ll want to consider, as deciding on which approach to take will largely depend on several factors:
Build a custom CIAM solution if you have specific, unique needs that require extensive customisation and full control over security, compliance, and integration with internal systems. This approach is most suited for large enterprises with significant resources, but it’s not for the faint-hearted!
Buy a vendor-made SaaS CIAM solution if you need a quick, secure, and scalable solution that handles all the complexities of identity and access management, with built-in compliance and security features. SaaS providers are ideal for businesses looking for a fast, cost-effective way to implement CIAM without the overhead of in-house development and maintenance.
DIY your CIAM solution for arguably the maximum flexibility, using a combination of open-source technologies, (optionally) vendor-built SDKs, and a minimal amount of bespoke “glue” and hosting to leverage the existing investment in your own infrastructure.
Ultimately, the choice comes down to your priorities, resources, and long-term vision for the identity and access management of your customer-centric application(s), and below, in true TL;DR fashion, is a table of comparisons providing an at-a-glance high-level view of the merits of each approach; if you’re using a mobile device then I’d recommend rotating (to a landscape orientation) to get a better view 😁:
As in whether or not there’s reliance on some third-party provider ↩︎
Method of Adoption
Understandably, then, when it comes to adopting CIAM, most feel they’re faced with an important decision: should we build our own CIAM solution or buy a ready-made offering? A post I recently came across on LinkedIn illustrates the build-vs-buy paradox quite nicely via a simple and easy-to-follow decision-making framework.
The majority see the build option as providing the most flexibility, but also the greatest challenge; one they’d rather avoid, and to be honest, one most experts would recommend avoiding too! While building everything yourself from scratch might seem favourable, identity is complex and time-consuming, and getting it wrong can be very costly!
The ready-made alternative is arguably the more attractive approach and was also discussed in a recent report on LinkedIn by the Aspect Dynamics Group. Buying a subscription to a CIAM SaaS solution — such as Clerk, FusionAuth, Frontegg, Auth0 by Okta, Firebase from Google, Cognito from AWS, or Entra ID as part of Microsoft Azure — is a popular choice.
However, vendor-provided offerings can carry a heavy price tag, particularly if you have a large user base or make extensive use of the features provided.
Both approaches have advantages and challenges, with factors such as business needs, security concerns, scalability, available resources and how much of your revenue you’re willing to spend affecting your choice. However, there is a middle ground that often gets overlooked.
With consumer-oriented software, though, much of the infrastructure you pay for in a vendor-provided SaaS solution may already be a requirement for the functionality you provide; cloud-based “compute”, database, network resources, etc. could be a necessity for your solution, and delivering these (at scale) already something you need to do.
A DIY (open-source) CIAM implementation — as in a pre-built (open-source) solution maintained and developed externally, but that you host within your infrastructure — could offer a different option, and one with the added benefit of enhanced flexibility at a much more cost-effective price.
DIY is the method of building, modifying, or repairing things by oneself. In this case, you can think of a DIY – or Deploy It Yourself – CIAM solution as tailoring an open-source implementation to suit your needs whilst minimising cost.
For example, a recent post on X suggests the open-sourced and cross-platform ASP.NET Core Identity might be a good choice, particularly if you’re a .NET developer. Keycloak is another one to consider — as are Authelia and Authentik (neither of which I’ve used, but of which I’ve heard encouraging things).
Don't implement custom auth if you're a .NET dev.
ASPNET Core Identity might be all you need.
Identity gives you:
– Authentication – User management – Login, logout, refresh tokens – Roles and claims for authorization – External authentication providers (Google, Meta)
As already discussed, processing User ID and Password credentials is the tip of the iceberg…particularly as they’re fast becoming obsolete! In today’s modern environment, more standards-based approaches for CIAM involving the use of OAuth 2.0, OIDC and/or SAML are preferred — approaches that also offer enhanced functionality and the ability to interoperate with third-party Identity Providers (IdPs) and Authorization services. Feature functionality includes (but is not limited to):
MFA — additional authentication factors that go beyond the humble UserID and Password.
SSO — to minimise interactive login whilst also allowing multiple identities to be associated with any given user.
Social — leveraging Facebook, Google, Microsoft, LinkedIn, etc., thus offloading authentication and authorization to third parties.
Federation — allowing organisations to use their own IdP deployments for authenticating and authorising user access…an absolute cornerstone for any B2B SaaS application.
Passwordless — many see traditional passwordless as legacy technology, however, it still offers real value, particularly when it comes to identity validation/confirmation.
Passkeys — with Passkey implementations fast becoming the preferred route, biometric-style technology designed to be the de facto standard is set to replace the User ID and Password altogether.
Charting the course of any CIAM approach, however, especially a course that may seem easy to start with, could result in difficulties later. Perhaps even requiring a complete change of tact at some point — something which is less than ideal, especially if doing so would also hurt the user experience. So it is important to consider your requirements and strategy for both the short term and the long term.
A change of CIAM approach, for example, could lead to an invalidated session, requiring the user to log in again, irrespective of any established SSO.
Customisation and Control
One of the biggest advantages of building your own CIAM is the notion of having complete control over the architecture, features, and user experience. At least that’s the perception. Here, the view is that CIAM can be designed to meet the exact needs, integrating seamlessly with internal applications, legacy systems, and databases:
The perception of a requirement isn’t always what’s actually required, particularly if you base the characteristics of a contemporary solution on some legacy implementation that may not conform to modern best practices.
You can tailor features to match your specific requirements, such as implementing custom workflows for authentication, developing specialised user interfaces, or integrating with other proprietary systems.
If your business evolves or has specific needs that an off-the-shelf solution doesn’t accommodate, then your purpose-built implementation allows you to adapt quickly.
However, this level of customisation comes at a price: developing a CIAM system from scratch requires in-depth knowledge of security protocols, compliance requirements, and identity management frameworks, which can stretch your development resources.
Buying a ready-made SaaS solution can provide a convincing alternative, giving you enough flexibility out of the box to do 90% of what you need, whilst also providing customizable extension mechanisms to address most, if not all, of the last 10%. The downside is the ever-increasing price tag that this approach typically comes with.
A DIY open-source option can be just as effective yet much cheaper. A hybrid approach — as in a mix of pre-built technology combined with customised code — can get you exactly what you need with the minimum of domain-specialised knowledge, and where financial implications are limited to the costs associated with the (hosting) infrastructure.
Security and Compliance
CIAM is a highly complex domain, and any missteps could lead to data breaches, loss of customer trust, and legal consequences. Whilst building a bespoke system arguably provides you with full control (at least the perception of it), a ready-made SaaS solution will typically handle the complexities of securing sensitive customer data so that you don’t have to:
Data Protection: ensuring that data is encrypted at rest and in transit; that MFA is used as part of step-up authentication workflows for sensitive operations; and that robust session management practices are in force.
Compliance: adhering to global requirements such as GDPR (General Data Protection Regulation) and CCPA (California Consumer Privacy Act).
Compliance Certifications: undergoing regular audits and maintaining the necessary standard(s) to ensure compliance with privacy regulations.
Depending on your requirements, the open-source DIY route could provide the perfect compromise between the full control of a bespoke implementation and the convenience of a vendor-provided SaaS solution, allowing you to leverage industry expertise but at a fraction of the overall cost.
Scalability and Maintenance
If your consumer application is designed to handle large volumes of users, then scalability will be a major consideration. Your CIAM system must handle the growth of users and user-centric data without compromising performance. If your user base grows unexpectedly or your application experiences a sudden surge in traffic — e.g., during a product launch or sales event — your CIAM must scale seamlessly to support the demand.
With some vendor-provided SaaS solutions, this could be a challenge. Or you could see your costs grow significantly. With an open-source DIY approach, you’d typically leverage the uplift in infrastructure you’ll likely need for your own application(s), thus ensuring you meet the demands without incurring additional and unnecessary charges.
With certain B2C or B2B SaaS software solutions, the need for flexible and scalable infrastructure is already a prerequisite. So any (elastic) solution already employed would lend itself ideally to an open-source CIAM approach.
Ongoing updates, bug fixes, and feature enhancements will require a dedicated team of maintenance-oriented and security experts. Continuously updating and evolving to ensure a system remains secure and compliant as new security vulnerabilities are discovered and new regulations are introduced will require human capital and financial investment if you build CIAM yourself. Whilst a vendor-purchased SaaS implementation goes a long way to mitigate this, an open-source approach may offer a community-oriented compromise more aligned with your resourcing and available budget.
Time and Resource Requirements
Building a bespoke CIAM implementation in-house is a time-consuming process that requires a significant investment in both time and expertise on an ongoing basis. Depending on the complexity of your needs, it could take months or even years to develop, test, and deploy an effective system:
Expertise: You’ll need a team of developers, security experts, and compliance officers to build and maintain the system.
Costs: Beyond initial development, ongoing expenditures related to security, compliance, and maintenance can accumulate over time.
Given the challenges involved, building bespoke CIAM may only be feasible for large enterprises with substantial budgets and a team of experts. But even then, it’s seldom a recommended route.
If you have a team with expertise you can draw from and/or your consumer-oriented software solution(s) fall into the B2C or B2B SaaS category, then the open-source DIY route can be just as effective an option, yet at a much lower overall cost.
There are third parties that offer hosting for open-source implementations and charge via a subscription model. Don’t confuse this with a free-tier offering from a SaaS solution vendor, which will ultimately end up as a cost option with the potential for vendor lock-in.
Purchasing a vendor-provided SaaS solution offers the advantage of offloading all the effort, however, the price tag can run into the thousands or even hundreds of thousands annually for large-scale enterprise organisations.
Cost and Resource Efficiency
While vendor-provided SaaS CIAM solutions come with a subscription cost, they typically offer better cost efficiency than building a custom solution. They eliminate the need for in-house development, security, and maintenance teams, reducing long-term operational expenses:
Most vendor-provided SaaS costs are based on MAU (Monthly Active Users) as the base-level indicator of the impact on their platform. If you exclusively leverage a Social IdP for user authentication, say, that impact is reduced, but subscription charges will typically not reflect this.
Predictable Costs: SaaS providers typically charge based on the number of monthly active users or logins, together with the functionality used. This can be easier to predict and budget for than building a custom system, though it can be less deterministic on the occasions where increased scale is required.
Reduced Maintenance Burden: The SaaS vendor takes care of ongoing maintenance, security patches, and updates, so your internal team can focus on other business-critical tasks.
Depending on your requirements, a DIY implementation based on established open-source technology can be equally effective by leveraging the skills and expertise of the open-source community.
Speed of Implementation
Ready-made SaaS CIAM is typically faster to integrate when compared to building a custom solution. In the main, a vendor subscription will provide pre-built templates and user interfaces, drastically reducing the time to market.
Out-of-the-Box Features: Most SaaS CIAM subscriptions include a wide range of pre-configured standards-based authentication methods, including Social logins, MFA, passwordless authentication, and more.
Rapid Deployment: Cloud-based implementations allow for quicker deployment with minimal setup required, reducing the time to build your application.
SDKs: For both client and server-side implementations, this means it’s easy to incorporate the best-practice workflows and guidance that ensure safe and secure integration.
Pre-built Components: For building user interfaces, particularly when it comes to profile management and supporting regulatory compliance standards (such as GDPR).
Most of the major players in the vendor-provided SaaS CIAM market offer free-to-use open-source SDK packages that are not linked to their respective SaaS platforms. Using standards-based OIDC and OAuth 2.0 flows often means you can use these with any DIY CIAM SaaS solution.
A DIY solution based on open-source technology can provide similar benefits, particularly when it comes to out-of-the-box features and rapid deployment. An implementation such as Keycloak, for example, offers a feature set comparable to the leading SaaS CIAM vendors. In addition, you can leverage your own infrastructure for deployment, which means you can leverage your own mechanisms for deployment too.
Vendor Reliance
A downside to purchasing a SaaS CIAM solution is the potential for overreliance on a vendor, often referred to as vendor lock-in. If your business grows or changes, it might be challenging to migrate away from the SaaS solution to another provider or some in-house implementation.
Data Portability: Ensure that your provider allows for easy export of user data and integration with other systems in case you decide to switch in the future.
Platform Resilience: The performance, uptime, and security of your CIAM system are reliant on the vendor platform, which may present risks in case of service disruptions or attacks.
With a DIY open-source approach, this isn’t typically an issue. Again, systems like Keycloak give you the choice of where to store user-centric data as well as the ability to leverage the disruption protection mechanisms you likely already deploy.
In fact, with an open-source implementation, CIAM and the bespoke functionality of your consumer-oriented software solution can become atomic — thus you no longer need to cater for vendor-hosted CIAM being down whilst your services are still up and running. Or vice versa.
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
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.
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.
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
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.
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).
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.
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.
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.
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
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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 Cloudflarehere
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 Enclaveand 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.
Leave a Reply