What is Identity? - The Question Every Team Should Answer Before Writing Code

The hardest part of starting with Duende IdentityServer and identity infrastructure isn't configuring endpoints or choosing grant types. It's answering a deceptively simple question: What is identity?

Most teams skip this question. They treat identity as a solved problem. Something you bolt on, a login page, a checkbox on the requirements doc. "We'll add auth" gets dropped into a sprint like any other task. Then, six months later, the rewrites start.

Identity implementations resist shortcuts. The teams that thrive with the task are the ones who slow down early, ask probing questions, and treat identity as an architectural conversation, not another ticket in a growing backlog.

Identity, Piece by Piece

If you're an architect bringing your team into this space for the first time, you need a shared vocabulary. Here's the terrain:

Authentication is proving who someone is. A user entering a password, a device presenting a certificate, a service exchanging a secret. The question being answered: "Are you who you claim to be?"

Authorization is deciding what someone can do once you know who they are. Roles, permissions, policies, scopes. Authentication unlocks the door; authorization decides which rooms you can enter.

Claims are portable facts about a user. Their email, their role, their department, their subscription tier. Claims travel with identity across system boundaries, carried inside tokens.

Tokens are the currency of trust between systems. When Service A tells Service B, "this user is allowed to do this," a token is the mechanism by which that trust is communicated without forcing the user to re-authenticate.

Federation is the act of trusting identity across organizational boundaries. Your company trusts Google, Microsoft Entra, Okta, and others to authenticate your users. A partner's system trusts your identity provider. Federation is the agreement that someone else's "yes, this is them" is good enough for you. Note that federation can be across multiple protocols like OpenID Connect and SAML.

Sessions define the lifecycle of "logged in." When does it start? When does it end? What happens when a user is active on three devices? Sessions are where theory meets the messiness of real user behavior.

Protocols (OpenID Connect, OAuth 2.0, SAML) are the shared language that makes all of this interoperable. They're the reason your identity provider can talk to applications built by different teams, in different languages, deployed to different infrastructures.

You don't need to master every one of these on day one. But you need to know they exist, because your implementation will eventually touch all of them. Teams that start coding without this map end up building workarounds for territory they didn't know was there.

Why This Isn't Simple

Identity is deceptively complex, and it can humble you if you aren't mindful. Let's see how things can quickly get out of control.

It crosses every boundary in your system. Your frontend, your APIs, your mobile apps, your background services, your third-party integrations. Identity is the one concern that flows through all of them. A decision you make in one layer cascades everywhere else.

The definition of "who" keeps expanding. You start with customers logging in through a browser. Then you add employees accessing internal tools. Then service-to-service communication. Then partner access. Then IoT devices. Each new actor type adds dimensions to your identity model.

The consequences are delayed. Bad identity architecture doesn't fail loudly on day one. It erodes velocity quietly over months. The team builds a workaround for one edge case. Then another. Session handling gets inconsistent across services. Permission checks are scattered and duplicated. Release targets start slipping. Users hit weird UX: they're logged out unexpectedly, or they can access things they shouldn't, or onboarding requires three separate credential ceremonies.

By the time the pain is acute, the fix is a rewrite. And as we all know, rewrites are expensive in terms of time, money, and overall organizational morale.

The teams that struggle most aren't lacking talent. They're lacking the early conversation that would have surfaced these questions before the codebase made them expensive to answer.

What Belongs to an Identity?

Before you can implement identity, you need to model it. And modeling means drawing boundaries: what's intrinsic to the identity itself, and what's contextual to a particular system?

This distinction matters more than most teams realize early on.

The identity vs. the profile. A user's email and authentication credentials are their identity. Their shipping address, notification preferences, or subscription tier might be stored elsewhere entirely. Where you draw that line affects how portable and reusable the identity is across your systems. Pack too much into the identity, and it becomes rigid. Keep it too thin, and every application reinvents user management.

One person, many contexts. The same human might be a customer in one system, an employee in another, and an admin in a third. Do they have one identity with multiple roles, or multiple identities? Both are valid, but they have very different architectural consequences. The first is simpler to manage. The second is simpler to isolate.

Cross-system identity. When three applications share an identity provider, what's the source of truth for profile data? Does each app maintain its own view of the user, or do they all read from one canonical record? The answer shapes your data flow, your consistency guarantees, and your coupling.

Cross-org identity. Partners, contractors, acquired companies. When someone exists in two organizations, how do you reconcile that? Linked accounts? Federation? Separate identities with a trust relationship? Each approach carries tradeoffs in complexity, user experience, and security posture.

What travels in the token vs. what gets looked up. Claims in a token should be stable, small, and relevant to authorization decisions. Putting volatile or bulky profile data in tokens creates coupling and performance problems. If a value changes frequently or is large, it probably belongs behind an API call, not inside a token.

Identity modeling is where architecture meets product decisions. The answers aren't purely technical. They depend on how your organization thinks about users, ownership, and trust. Which brings us to the questions your team needs to answer together.

What Does Identity Mean to Your Team?

This is the part that no documentation, blog post, or conference talk can answer for you. Identity means something different to every organization, and discovering your specific answer is a group activity.

Grab a whiteboard. Get your architects, your tech leads, your security people, and your product owner in a room. Work through these questions together:

Who are our users? Customers? Employees? Partners? Other services and machines? Some combination? Each user type likely has distinct authentication requirements, trust levels, and lifecycle expectations.

What does "logged in" mean to us? Is it a browser session? A token with a 15-minute lifetime? Does it persist across devices? If a user is active in your mobile app and your web app simultaneously, are those the same session or different ones?

What systems need to trust each other? Draw the boundaries. Which services need to know who a user is? Which ones need to make authorization decisions? Where does identity information flow, and where should it stop?

Who owns identity in our organization? Is it engineering? InfoSec? IT? Product? If the answer is "nobody, really," that's your first problem to solve. Identity without ownership becomes everyone's side project and nobody's priority.

What does failure look like for us? When authentication breaks, what goes down with it? Which systems go dark? Which users are locked out? How do you recover? The answers here inform how much redundancy and operational investment your identity infrastructure deserves.

Where are we going in the next 12 months? Are you adding new client applications? New user types? New compliance requirements? Expanding to new regions with data residency laws? Your identity architecture needs to accommodate where you're headed, not where you are today.

These questions don't have right or wrong answers. They have your answers, specific to your organization, your users, your risk tolerance, and your product roadmap. The act of answering them together is what turns "add auth" from a vague sprint task into an informed architectural decision.

You Don't Have to Figure This Out Alone

The team behind Duende IdentityServer and its partner network has spent over a decade helping organizations answer these questions. That experience is baked into the product, but more importantly, it's baked into the documentation: architectural guidance, protocol explanations, implementation patterns, and the accumulated knowledge of thousands of teams who've walked this path before you.

Start with the documentation. Bring your team's answers to those six questions. You'll find that the distance between "we understand our identity needs" and "we have a working implementation" is much shorter than the distance between "we'll figure it out as we go" and "why is everything broken."

The question "What is identity?" has both a broad and a personal answer. The broad answer gives you vocabulary and orientation. The personal answer gives you direction. You need both before you write code.