identitaet

Identity

In short: In a security context: the set of attributes by which a user, device or system can be uniquely identified — the basis for authentication and authorisation.

In more detail: Digital identity can refer to people (user account), devices (a certificate on an end device) or services (server certificate). Proof of an identity usually runs via one of three factors: knowledge (password), possession (hardware token, smartphone) or inherence (fingerprint). Combining several factors is the basis of 2FA.

In Depth

Identity and authentication are often confused, but describe different steps:

Identification   - "I am admin@company.com" (a claim, unchecked)
Authentication   - "Prove it" (password, certificate, biometric feature)
Authorisation    - "OK, you're admin@company.com — what are you allowed to do now?"

Identity is the starting point of the whole chain: without a clearly defined, unique identity, you can neither authenticate meaningfully (whose authenticity is to be checked?) nor authorise (which rights apply to whom?). In complex systems, identity is therefore often managed centrally — via so-called identity providers (IdP), which check a person’s identity once and then pass this result on to several other systems (single sign-on), instead of each system managing its own credentials.

Besides human identities there are increasingly non-human ones too: an end device can have its own machine identity via a client certificate (e.g. an IoT sensor that identifies itself to a server), and automated services or APIs also authenticate with each other via their own identities (e.g. API keys or service accounts), with no human involved at all.

Identity providers and single sign-on in detail

The principle of an identity provider (IdP) solves a real practical problem: without central identity management, a user would have to log in separately with their own credentials for every single application of a company (email, internal tools, calendar, ticketing system) — impractical for users and a security risk, because every additional set of credentials represents another potential entry point. With single sign-on (SSO), the user logs in ONCE with the central identity provider (e.g. via Microsoft Entra ID or Okta), which then issues a cryptographically signed token for every further application confirming the already verified identity — the individual applications themselves only check this token instead of maintaining their own password databases.

Identity theft as a target of attack

Because identity is the basis for both authentication AND authorisation, many attacks aim directly at stealing identity attributes rather than exploiting technical vulnerabilities — phishing, credentials stolen from other services’ data leaks (credential stuffing, in which attackers automatically try email/password combinations leaked at service A on service B, hoping for password reuse) or identity theft in the literal sense (someone uses stolen personal data to pose as another real person, e.g. to take out a loan in their name). This explains why modern security concepts increasingly rely on “identity as the new perimeter” — instead of relying primarily on network boundaries (firewalls), reliably verifying EVERY single identity on EVERY access becomes the central protective mechanism (see also the zero-trust security model).

Federated identity

Beyond a single organisation, there’s the concept of federated identity: instead of creating a separate account for every service, a user can use an existing identity at a large provider (e.g. “Sign in with Google”, “Sign in with Microsoft”) to log in to completely unrelated third-party services too — technically usually implemented via open standards such as OpenID Connect or SAML. The third party then doesn’t have to maintain its own password database and bears correspondingly less responsibility for protecting the credentials, but relies entirely on the trustworthiness of the federated identity provider.

See also: Authentication, Digital ID, Authenticity