What is a Claims Authority?
On this page
When a claim is issued, there is an assertion that the value associated with the claim name is true. The entity providing the assertion is called an asserting party. However, the claim itself has something called an authority--the place where it was asserted. Normally the asserting party and the authority are the same, but sometimes they are not.
The Claims Authority Process
An authorization server (an identity provider) acts as a claims authority. In almost all cases, the claims issued are fetched from a data source or derived from a context that is in the identity server's control.
When this happens, the authorization server is the claims authority. Any claim that is stated in a token (ID token or access token) with no additional metadata is considered to have been issued by the current issuer.
The Role of the Issuer
OpenID Connect specifies the iss field to be used in ID tokens to describe who the issuer of the token is. The issuer is the one who assembles the token and signs it (for signed JWTs). The iss field should be an HTTPS URL pointing to the identity provider.
If a token is received with issuer address other than the identity provider currently in use, it will have a different authority. It is important to understand that any claim in such a token is asserted by that issuer, not by the Identity Server.
This can happen if the server is configured to embed tokens inside tokens and these embedded tokens have been received from other parties, such as Facebook or Google.
Types of Claims
OpenID Connect defines three types of claims:
Normal Claims
Directly asserted by the OpenID Connect Provider (OP), these claims are sourced from trusted identity providers (IdPs).
Example
{"sub" : "johndoe","email": "johndoe@example.com"}
Aggregated Claims
Collected from external identity providers, these claims are included in tokens and are accompanied by metadata indicating their source. The value of these claims is not under the identity server's direct control. These are still interleaved with other claims, but two extra sections in the token exist to highlight the origin of these claims.
Example
{"sub" : "johndoe","email": "johndoe@example.com","some_service_id" : "123456","_claim_names": {"some_service_id": "src1",},"_claim_sources": {"src1": {"JWT": "jwt_header.jwt_part2.jwt_part3"}}}
The original ID Token from the other OpenID Connect Provider is included as a claims source. All aggregated claim names are listed as _claim_names.
Distributed Claims
Distributed claims are only included by reference, and the Client must resolve these with the original OpenID Connect Provider.
Example
{"sub" : "johndoe","email": "johndoe@example.com","_claim_names": {"some_account_status": "src1",},"_claim_sources": {"src1": {"endpoint": "https://api.example.com/claim_source"}}}
The distributed claim is not part of the ID Token but is only mentioned as name in _claim_names, and the location of the claim is then listed in the _claim_sources section.
It's also possible to include authentication information such as an access token in the _claims_sources that the client can use to retrieve the claims.
Claims in the Curity Identity Server
Understanding the function of a Claims Authority within the framework of identity management is essential for implementing secure and efficient authentication and authorization processes.
As noted, all claims issued by default are normal claims in the Curity Identity Server. However, it is possible to modify the token procedures to issue aggregated and distributed claims. When doing so, it's important to understand the formats to use and that the authority of the claim is important.
Read more
You can read more about claims in the OpenID Connect specification
Jacob Ideskog
Identity Specialist and CTO at Curity
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
Start Free Trial
