The Claims Authority

The Claims Authority

architect

What is a claims authority?

Overview

When claims are issued, someone is asserting that the value associated with the claim name is true. This 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 to what the authority is.


The Claims Authority

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 which is in control of Curity.

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 be issued by the current issuer.

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 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 another issuer address than the Identity Provider currently in use, it has a different authority, and it's important to understand that any claim in such token is asserted by that issuer, not by Curity.

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 the claims that are asserted directly by the OpenID Connect Provider, as described above. This is the normal case in Curity 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. So the value of these claims are not under direct control of Curity. These are still interleaved with the 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 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 the _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 for the client to use to retrieve the claims.

Claims in Curity

As noted all claims issued by default are normal claims in Curity. However it's possible to modify the Token Procedures to issue Aggregated and Distributed claims. If doing so it's important to understand the formats to use, and that the authority of the claim is important.


Read more

It's recommended to read more about claims in the OpenID Connect specification before going in-depth with different authorities.

Was this page helpful?