Claims-based identity


For some applications, working with user identity is simple. Consider a Windows application that is accessed only by users in a single organization and does not need to know much about those users. This application can simply rely on Kerberos, part of Active Directory Domain Services (AD DS), to authenticate its users and convey basic information about them. Or consider an application that is accessed only by Internet users. This application can simply require each user to supply a username and password, and it can store this user information in a database.

However, for most applications, working with user identity is more complex. Consider an application that needs more information about each user than is provided by either Kerberos or a simple username and password. The application has to acquire this information from some other source, such as AD DS or store the information itself. Or consider an application that must be accessed both by employees inside the organization and by Internet users. The application must support both Kerberos and username and password based logins. Finally, suppose the application must be accessed by a different organization without requiring a separate login. This identity federation can’t be accomplished very well with either Kerberos or username and password logins.

Claims-based identity provides one approach to identity that works in all of these scenarios. It is based on widely recognized industry standards that work across both platform and organizational boundaries. It is also widely implemented in products from multiple vendors, and it is simple for developers to use.


Claims-based identity is a common way for applications to acquire the identity information they need about users inside their organization, in other organizations, and on the Internet, and it also provides a consistent approach. Claims-based identity abstracts the individual elements of identity and access control into two parts: a notion of claims, and the concept of an issuer or an authority.

Claims-based identity

A unique identifier that represents a specific user, application, computer, or other entity. It enables that entity to gain access to multiple resources, such as applications and network resources, without entering credentials multiple times. It also enables resources to validate requests from an entity.


A statement that one subject makes about itself or another subject. For example, the statement can be about a name, identity, key, group, privilege or capability. Claims are issued by a provider and they are given one or more values and then packaged in security tokens that are issued by a Security Token Service (STS).


Security tokens are used to prove an identity electronically. Claims are packaged into one or more tokens that are then issued by an issuer (provider). It holds information about a user or a resource.

Security token service

A security token service (STS) is the service component that builds, signs and issues security tokens according to the claims-oriented protocol used.


Claims-based identity has the potential to simplify authentication logic for individual software applications, because those applications do not have to provide mechanisms for account creation, password creation and reset etc. Furthermore, claims-based identity enables applications to know certain things about the user without having to interrogate the user to determine those facts. The facts, or claims, are transported in an envelope called a secure token.

Claims-based identity can greatly simplify the authentication process because the user does not have to sign in multiple times to multiple applications. A single sign-on creates the token which is then used to authenticate against multiple applications, or web sites. In addition, because certain facts (claims) are packaged with the token, the user does not have to tell each individual application those facts repeatedly, for example by answering similar questions or completing similar forms.


When you build claims-aware applications, the user presents an identity to your application as a set of claims. One claim could be the user’s name, another might be an e-mail address. The idea here is that an external identity system is configured to give your application everything it needs to know about the user with each request she makes, along with cryptographic assurance that the identity data you receive comes from a trusted source.