Authentication is the process of identifying access to a system to secure the functionality it provides.
Authentication, however, isn’t just about security: a good authentication solution can help you provide a consistent experience no matter how your application is used.
Hi, I’m Peter Fernandez, and as a CIAM expert, I want to share my experience building modern Authentication (a.k.a. AuthN) into modern applications.
User Credentials
Using user-based credentials (e.g. User ID, Password, etc.) the process of identification based on an actual user is typically performed via the interactive Login process with which we’re all familiar. But even if your application doesn’t require secure access, implementing user-based authentication can still enable you to provide your users with consistency — like a consistent profile context, which they can take with them no matter how they log in.
Client Credentials
Whilst most applications will operate on behalf of a user, there are circumstances where there is no human interaction. This can occur between services, machines, or devices when they need to communicate securely with each other — either in a foreground or background context. In such cases, a known set of credentials is utilized instead of an (interactive) Login and is typically supported in situations where a user was never present at all.
Login vs…
Login, also referred to as SignIn, typically starts with an interaction where a user supplies their credentials for verification. Credentials come in a number of different forms, the most familiar being the UserID and Password. But forms associated with Passwordless authentication, Passkeys, Social, and (Enterprise) Federation scenarios exist too. Once credentials are verified, an application will typically establish the session for the user, with, optionally, an SSO context established too.
…Logout
The converse process is known as Logout. Once a user has finished interacting with an application, they will typically terminate their session explicitly via a logout, effectively de-authenticating. Or, alternatively, the application will terminate their session implicitly if no user interaction has occurred for a period of time. Optionally, a Logout can also terminate any SSO context — so that the user must again engage with the Login process interactively if they wish to continue.
First-Factor…
The degree to which user authenticity (and, in some cases, client authenticity) needs to be proven can vary considerably. First-factor authentication — typically known as (User)ID & Password authentication, but can also include the likes of Social or Passwordless authentication — is always a given. However, certain scenarios, such as those that involve performing financial or security-sensitive transactions, often benefit from the use of one or more additional factors.
…vs Multi-Factor
Multi-factor Authentication, typically known as MFA, refers to the process whereby one (or more) factors are performed in addition to whatever first-factor authentication occurs for a user. MFA — also known as 2-factor Authentication (or 2FA) where only one additional factor is used — provides for the additional verification of a user. MFA can occur immediately after First-Factor authentication or, in cases where SSO is utilized, under certain conditions typically referred to as Step-Up Authentication.
Click to visit
Authentication vs Authorization
Whereas Authentication is the process of identifying access to a system, Authorization — a.k.a AuthZ — is typically referred to as the process of determining exactly what access is allowed and invariable requires Authentication as a pre-requisite!
Authentication Architectures
Authentication in a CIAM context comes in all shapes and sizes. From B2C scenarios, where users are your direct customers, to B2B and B2B2C scenarios where users are employees or other people’s customers too. With workflows optionally using Passwordless, Passkeys, MFA, Social and Federation, through service level access using client credentials and the various combinations in between, there are numerous potential situations you’ll need to consider.
Buy vs DIY
You could build an in-house custom solution yourself…it’s certainly an option. Particularly if you have a team with the time, capacity, knowledge, and expertise to develop SSO; deploy and maintain Attack Protection; leverage OIDC and/or SAML for Authentication, Social and/or (Enterprise) Federation; implement Passwordless, Passkeys and/or MFA, and/or optionally OAuth 2.0 for API Authorization.
The alternative is to integrate with a SaaS solution provided by one of the popular vendors, and the cost of subscribing to one of these typically depends on the features you use and the number of active consumer identities you have.
With vendor-based CIAM the cost is typically associated with the platform hosting the backend service(s) that deliver Authentication, Authorization, Management and Protection from attack. With consumer-oriented software, much of this infrastructure is already in place: cloud-based “compute”, database, network resources, etc. could be a necessity for your solution, and delivering these at scale may be something you also need to do.
Deploying a standards-based open-source DIY solution within your existing infrastructure might provide a more cost-effective approach — delivering secure and robust CIAM without the need to build everything yourself and with the added benefit of more flexibility and control.
Got questions?
Feel free to reach out!
