Identity vs authentication: why a login is not an ID

Authentication answers “is this the same person as before?”, while identification and identity proofing answer “who is this person?”. A login can be extremely secure and still tell a service nothing reliable about who you are. Mixing these questions up is behind many security failures and many privacy problems, because services collect identity documents when a login would do, and trust a login when they actually need proof of identity.

Four questions, four names

Question	Name	Example	Typical technology
Who do you say you are?	Identification	Typing a username, giving a name or customer number	Identifier, claim
Is that claim true in the real world?	Identity proofing or verification	A bank checks your passport, an authority checks the national register	eID, document check, in-person check
Are you the same one who registered?	Authentication	Signing in with a passkey, a one-time code or a hardware key	Passwords, passkeys, TOTP, security keys
What are you allowed to do?	Authorisation	Read-only access versus admin rights, approve a payment	Roles, policies, OAuth 2.0 scopes

The US National Institute of Standards and Technology draws the same line in its Digital Identity Guidelines (SP 800-63), which treat identity proofing, authentication and federation as separate parts with separate assurance levels. The eIDAS Regulation in Europe also grades both aspects, as we explain under levels of assurance.

Why a login is not an ID

Think of a gym membership. The staff scan your card at the door, and that is authentication: the card is the same one issued to you. It tells the gym nothing about your legal name unless they asked for ID when you joined. Online it works the same way:

• A passkey proves that you hold a private key registered on an account. The service does not learn your name from it. See passkeys explained.
• A second factor such as an authenticator app raises the confidence that the person logging in is the account owner. It does not add any identity information. See two-factor authentication.
• An email address is an identifier you control, not proof of a legal identity. Anyone can create one with any name.
• A “Sign in with” button tells the service that an identity provider authenticated someone it calls by a certain identifier. The name and email claims are whatever the provider has on file, and the provider may not have verified them.

This is why a platform can have millions of users it can recognise instantly and still not know who any of them really are. Anonymity or pseudonymity is often fine and even desirable: you do not need to prove your name to read a forum. The trouble starts when a service that needs real identity, such as a bank or a government portal, relies on a plain login.

Where OpenID Connect fits

OpenID Connect (OIDC) is the standard that lets one service rely on another to authenticate a user. It is built on OAuth 2.0 (see OAuth 2.0), which handles authorisation, and adds an ID token: a signed statement that a user authenticated at a certain provider at a certain time, with optional claims such as name or email. The specification is at openid.net, and our page on OpenID Connect explains it in more detail.

What OIDC does not do by itself is guarantee that the claims are verified. The relying service decides how much to trust the provider. If it needs verified identity data, it must ask for it and the provider must be able to supply it, for example through the OpenID Connect for Identity Assurance extension or through a government-grade eID. Our history section, for example the story of how OpenID became OpenID Connect, shows how the original OpenID was also an authentication protocol and why it did not carry identity proof.

What this means for EU digital identity

In the EU framework the separation is explicit.

• eID schemes under eIDAS combine identity proofing and authentication. A scheme at assurance level “high” requires a strict enrolment check and a strong authenticator, which is why it can be used for government services and bank onboarding.
• The EUDI Wallet keeps the two apart. The wallet holds attestations, such as person identification data issued by a government. Unlocking it with a PIN or biometrics is local authentication. Presenting an attestation to a service is proof of identity attributes. The service chooses which attributes it asks for.
• Age and attribute checks often need no identity at all. Proving “over 18” is a claim about an attribute, not about a person’s name.

The EUDI Wallet guide covers how these pieces fit together.

Practical rules of thumb

1. For services: ask yourself whether you need to recognise a returning user or know who they are. Recognition needs authentication. Knowing needs identity proofing at a stated assurance level. Collect the minimum.
2. For users: strengthen authentication everywhere with passkeys or a second factor, and share identity documents only with services that have a legal reason to ask for them.
3. For developers: do not treat an OIDC email claim as verified identity unless the provider says it is. Check the claims about verification.
4. For everyone: if someone says “we verified you with a login”, ask what was verified and by whom. See also our primer on what a digital identity is for the broader picture.