Whilst the SPA paradigm has grown in prominence over the years, little has changed in the guidance provided for integrating Customer Identity. With the necessity to provide a compelling UX, whilst protecting from attacks like XSS, this article introduces the ACME pattern and how it has been designed to tackle the challenge.
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.
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.
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
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
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.
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.
You can learn more about OAuth 2.0, and the role of an Authorization Server, in the article at: Discover/CIAM/OIDC, SAML and OAuth 2.0
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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).
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.
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.
Software-As-A-Service — more commonly known as SaaS — is a software delivery and licensing method in which software is accessed online via a subscription, rather than bought and installed on individual computers. SaaS solutions commonly come in two forms, B2C and B2B, representing the consumer audience to which they are targeted.
Discover more about SaaS CIAM in the article entitled: B2C and B2B SaaS Authentication Architectures
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).
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 working behind the scenes, acting in or directing a show at my local theatre.
Follow me and learn more about Customer Identity at: Discover/CIAM
