Identity Layer

Almost every online service needs to know two things: who is currently in front of it, and what is this person allowed to do? An identity layer is exactly the part of a system that answers these two questions. It takes in login credentials, verifies them, and then issues a kind of digital ID. All other parts of the system rely on this ID and don’t check it themselves. You can think of it like the reception desk in a large office building. There, you show your ID once, receive a card, and with that card the doors you’re authorized for open afterward.

Why login shouldn’t be solved by every app on its own

A company rarely runs just one program. It has a mail system, an accounting tool, a customer management system, and a dozen internal tools. If each of these stores its own passwords, a dozen places emerge where something can go wrong. Storing passwords securely is also surprisingly difficult, and every developer who tries to do it from scratch makes the same mistakes all over again.

A shared identity layer consolidates this in one place. When an employee quits, their access is deactivated once and is thereby blocked everywhere. Without a central layer, accounts often remain in forgotten systems, and those are precisely the ones that later become a point of entry. Requirements such as two-factor login can also be turned on centrally once instead of twenty times.

In the context of AI, this topic has taken on new significance. More and more software acts autonomously: programs call other programs, make bookings, place orders, or read out databases. Such automated actors also need an identity and clearly limited permissions. An assistant program that reads calendar appointments shouldn’t be able to trigger bank transfers.

ID, token, and the question of authorization

Technically, two steps are kept separate. Authentication clarifies whether someone really is the person they claim to be, usually via password, a code on a phone, or a fingerprint. Authorization then clarifies which actions this person is permitted to perform. Both steps sit within the identity layer, but they are separate decisions.

After successful verification, the system issues a token. This is a small, digitally signed file containing information such as username, roles, and expiration time. The browser or app sends this token along with every further request. The service being addressed only checks the signature and never has to see the login credentials. Tokens are deliberately set to expire quickly, often within minutes, so that a stolen token is of little use.

For different providers to work together, standards exist. OAuth governs how a service gets limited access to data held by another service. OpenID Connect builds on top of this and adds the actual identity verification. That’s why the “Sign in with Google” button works the same way on thousands of websites.

From the login button to the national ID app

An identity layer becomes most visible when logging in via a third-party account. Anyone who logs into a game or shop using Google, Apple, or Microsoft is using that provider’s identity layer. In doing so, the shop only learns the bare minimum, such as name and email address, but never the password. In schools and companies, this principle is known as single sign-on: one login in the morning, after which all programs work.

Government systems also fall into this category. The online ID function of the German national identity card and the planned European identity wallet are identity layers for government services. At banks, legal checks are added on top, such as proof of identity when opening an account.

In business news, the term comes up in discussions of market power. Whoever controls the identity layer sits at the gateway to many other services. A common misconception is that an identity layer automatically makes a system secure. It merely concentrates risk at one well-protected point. If that point fails or is breached, all connected services are affected.