What is a Claims Authority?

Overview

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.

This article gives a brief overview of what a claims authority is.

The Claims Authority Process

The Curity Identity Server 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 Curity's control.

When this happens, Curity is the claims authority. Any claim that is stated in a token (ID Token or Access Token) with no additional meta-data is considered to have been issued by the current issuer.

The Issuer

OpenID Connect specifies the iss field to be used in ID Tokens in order to describe who the issuer of the token is. The issuer is the one that assembles the token and signs it (for signed JWTs). The iss field should be a 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 Curity 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

These are claims that are asserted directly by the OpenID Connect Provider, as described above. This is the normal case in the Curity Identity Server and almost all claims are considered normal claims.

Example

{
  "sub" : "johndoe",
  "email": "johndoe@example.com"
}

Aggregated Claims

These are claims that are asserted by another OpenID Connect Provider but included in the tokens returned by Curity. The value of these claims is not under Curity'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 Curity

As noted, all claims issued by default are normal claims in Curity. 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 OpenID Connect specification

Published: 2019-03-22

Jacob Ideskog

Identity Specialist and CTO at Curity