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.
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. With workflows using SSO, 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.
Authentication Architecture
From a CIAM perspective, the preferred mechanism of choice when it comes to Authentication should be the use of an Identity Provider. An Identity Provider, commonly referred to as an IdP (or IDP), is typically deployed as an application-independent centralised service and is responsible for verifying a customer’s identity when they attempt SaaS solution access. An IdP will leverage industry standards, such as OIDC, enabling the likes of SSO via the various first-factor authentication methods to maintain a seamless user experience.
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, such as 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 utilised 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 sign-in, 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, optionally with 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. Alternatively, the application will terminate the 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, etc. — 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 utilised, under certain conditions typically referred to as Step-Up Authentication.
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 invariably requires Authentication as a pre-requisite!
Click to follow
Build vs 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,
- Leverage OIDC and/or SAML for Authentication, Social and/or (Enterprise) Federation,
- Implement Passwordless, Passkeys and/or MFA, with optional
- OAuth 2.0 for API Authorization, as well as
- Deploy and maintain Attack Protection.
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 SaaS, 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.
Questions? Comments?
Feel free to reach out!
