This post looks at authentication and identity validation and describes what should be validated and some of the concepts. With the increasing push to move processes to a digital world and the new threat models, authentication and identity validation MUST be implemented in a professional way. Using standards like OpenID Connect, OAuth and OpenID VCs is the recommended approach.

What is authentication?

Authentication is the process of verifying an identity, which can be a user, a system, a device, a bot, an AI agent or an application. In a web application with user interaction, the application and the user are authenticated. An OpenID Connect public client does not authenticate the application and SHOULD not be used for web applications.

What is Identity?

A digital identity is the online representation of an individual, organisation, or device that allows software to authenticate the identity. A user can have multiple identities. The identity is normally shared as a set of claims returned in a signed token from a trusted identity provider.

Level of authentication (loa)

There are different levels of authentication and each level can only be trusted, if the level of authentication is understood. In the list underneath, 1 is the best authentication method and 4 is the worst. Passkeys authentication is the best way of implementing authentication and in the list, it is the only one which is phishing resistant. Secure authentication only uses phishing resistant authentication, including recovery flows. Authentication apps like Microsoft, Google, PING ID and OKTA authenticators are NOT phishing resistant and are not as secure as passkeys. OpenID verifiable credentials are in this category as well. This should not be used for authentication in administrator business cases or for high security uses cases. The third group include 2FA flows using SMS or email authentication. Any authentication process which can be automated is not really safe as bots, AI agents can automate this as well. MFA using TOTP is no longer a safe way of implementing authentication. This is used a lot for enterprise shared accounts. This group is really two-step authentication and not 2FA. The 4th category is the worst and should be avoided. An example of this is a Firewall key used to protect Firewalls in enterprises or single factor passwords.

1. passkeys, (public/private key certificate authentication)
2. authenticator apps, OpenID verifiable credentials (E-ID, swiyu)
3. SMS, email, TOTP, 2-step
4. single factor, SAS key, API Keys, passwords, OTP

Level of Identity (loi)

All identities are created in different ways. How an identity is created and validated is critical in a digital world and an identity can only be trusted to different levels. It is important that software should communicate the level of identity so client applications can validate this. There are different ways of creating digital identities. In the following list, 1 represents the highest level of trust, and 5 the lowest.

1. Offline Human identification by trusted official in trustworthy organisation.
2. OpenID verifiable credentials (E-ID, swiyu), government issued.
3. Digital online check with person
4. Digital video without person
5. Email & SMS validation

Professional authentication and identity verification

For a professional authentication and identity check in the digital world, both the authentication level and the identity level should be shared in an authentic form and validated, i.e. a signed token using some OpenID, OAuth standard. This could be implemented as follows:

• A user (person) creates an account on an identity provider
• A user adds authentication methods using 2 or more passkeys
• User authenticates using passkeys and user the identifies himself/herself using OpenID verifiable credentials (E-ID, swiyu). The required identity data is persisted to the account and cannot be changed unless updating using OpenID verifiable credentials (E-ID, swiyu) and the required checks.
• User can authenticate online using OpenID Connect with passkeys authentication. Example: Web application: OIDC confidential client using PAR and client assertions, OAuth DPoP for access token.
• The level of authentication (loa) and the level of Identity (loi) claims representing an authenticated identity are returned in an id_token, (DPoP access token if required). The tokens are signed using a recommended asynchronous encryption and the client validates the signature. The client MUST validate the claims for sensitive flows, for example E-Collecting.

Notes

Once an account uses passkeys and has identified using OpenID verifiable credentials, the user no longer needs to use the OpenID VC identity check as the passkeys provide a higher level of authentication and is already connected to the identity. The identity is fixed to the account which is authenticated. Authenticating using verifiable credentials does not provide strong authentication, this is NOT phishing resistant.

In a follow up post, I will implement this using Duende IdentityServer and OpenID verifiable credentials implemented using the swiyu.

Links

The authentication pyramid

Implement ASP.NET Core OpenID Connect with Keycloak to implement Level of Authentication (LoA) requirements

https://github.com/damienbod/sien-agov-poc

OpenID for Verifiable Credential Issuance

OpenID for Verifiable Presentations

https://duendesoftware.com/blog/20250701-step-up-challenges-for-aspnet-core-client-apps-with-duende-identityserver

Challenges to Self Sovereign Identity

Is scanning QR Codes for authentication safe?

Problems with online user authentication when using self sovereign identity