Zero trust in consumer/B2C authentication

A short primer on zero trust

Zero trust is a security model that assumes that no user or device can be trusted, even if they are inside the network perimeter. This means that organizations must verify the identity of every user, device, and application before granting them access to resources. Zero trust is based on the principles of verify explicitly, use least-privileged access, and assume breach.

Verify explicitly means that organizations should verify the identity of every user, device, and application before granting them access to resources. This can be done through a variety of methods, such as multi-factor authentication, risk-based authentication, and behavioral analytics.

Use least-privileged access means that users should only be granted the access they need to perform their jobs, and no more. This helps to reduce the risk of unauthorized access to sensitive data.

Assume breach means that organizations should assume that their systems have already been breached, and that they should take steps to minimize the damage that an attacker can do. This includes implementing strong security controls, such as zero trust identity, and having a plan for responding to a breach.

Up until most recently zero trust principles have predominantly been applied to workforce identity use cases, alleviating archaic forms of network and application access controls like internal access via VPNs and transforming how organizations on-board and off-board employees.

The same principles can also be applied to consumer identities and authentication, and even more important to implement especially with the advent of rampant data breaches, session hijacking, and the exploitation of weak symmetric authentication factors like (passwords, pins, knowledge based answers - KBA, one time passwords OTP)

Applications of Zero Trust Identity in Consumer Authentication

• Strong Multi-factor authentication. This is a type of authentication that requires users to provide two or more pieces of evidence to prove their identity, that is phishing resistant like Passkeys and FIDO2 security keys.
• Risk-based authentication. This is a type of authentication that takes into account the risk level of a particular transaction when determining the level of authentication required.
• Behavioral analytics. This is a type of authentication that analyzes user behavior to identify suspicious activity

‍

Practical zero trust policies to implement in the context of consumer applications

• Challenge with MFA as a default - Assume sessions have been hijacked or symmetric credentials breached, and apply a step up challenge flow as a default
• New Device Risk - New devices are always a strong risk signal, track device ID's or fingerprints, and timestamp last MFA attempt
• Device last authenticated timestamps - With friendly fraud on the rise, and poor consumer controls on devices (like lock screens, shared family devices) assume that the long lived sessions are prone to risk, create windows where there is high assurance that the user was who they said they were since the last successful authentication attempt and only forgo step up authenticaion if comfortable
• High risk transactions - Regardless of legitamacy high risk transactions like high withdrawal amounts, and high velocity of transactions within a short window, transfers to new bank account numbers always pose an element of risk. The ability to offer a step up offers an important buffer between the customer and the final authorization, and adds a layer of transaction signing that can be verified
• Behavior - Typically certain behaviors precede a high risk action, like changing a password, changing an address, followed by iniating a high value transaction. Being able to bring events in from disparate systems to build policies that have behavioral context allows effective targeting of specific bad actor behavior
• OpenID/OAuth2.0 Claims - Use context from a Open ID auth flow when an application/relying party is requesting acess, together wuth the scopes that it's requesting are a place to overlay zero trust policies i.e. you may have an application or third party app that is contains a higher risk profile or requesting for claims that are more priveleged
• Restrict authentication to high assurance factors - If the customer has opted in to higher assurance factors like Passkeys, Secuity Keys (Yubikey), Time based one-time passwords (TOTP) restrict the ability to use weaker factors

‍

Authsignal's Drop in Passwordless Authentication orchestration suite

The great news is that implementing zero trust security principles into your consumer applications is very simple with Authsignal. Regardless if you're using an identity provider like Auth0/Azure AD B2C (Entra) or have your own identity stack, Authsignal's drop in solution allows your team to deploy these zero trust customer journeys very quickly, with our OpenID Connect integrations or our single API call you can explicitly verify your customer at crucial touch points.

‍

Sign up for a free account and try out how easy it is to protect your customer accounts.