The audience claim specifies the intended recipient of a token.

OpenID Connect is a delegated authentication protocol. In simple terms, it’s a Single-On-On system. As a result, multiple services can use it for authentication, and each service can obtain tokens. These tokens are all signed by the same authority and are valid as such. If each service were to trust tokens from every other service, a user authenticating to one service would be granted access to all services.

The audience claim prevents this from happening.

A Use-Case

Consider a common scenario: a business offers several capabilities that are exposed through multiple channels, such as websites or internal applications. These applications are secured by a separate authorization server, which eliminates the need for a monolithic landscape:

Commonly, businesses have capabilities such as:

  • Human Resource Management
  • Order Management
  • Customer Relationship Management
  • Etc.

These business capabilities are used to automate processes. For example, to allow customers to check their order status.

To display the order status in the customer portal, the portal needs access to data from the Order Management system. At the same time, various back-office applications may need to access and update those same resources in order to automate background processes involved in order management.

However, a back-office application may need broad access across multiple internal systems. In contrast, a consumer-facing application typically requires much more restricted access.

For example, while back-office software might legitimately interact with HR, finance, and order management systems, a customer-facing portal should be tightly constrained to only the resources relevant to the customer experience. After all, a customer has no business accessing the HR system.

This is exactly the problem that the aud (audience) claim is designed to solve.

  • In this example, the Customer Portal, the Backoffice Portal, the Order Status API, and the Human Resource API are all considered clients.
  • Each client has an audience: a list of clients or services that are allowed to consume the tokens issued for it.
  • An audience can also include external APIs.

Configuring an audience in an Identity Provider alone has no effect. The audience must be configured in both the client and the Identity Provider:

  • The Identity Provider includes the list of allowed audiences in the tokens it issues.
  • The client must be configured to validate that any token it receives contains the correct audience.

The client_id, Aud- and the Azp Claim

As with many concepts in OpenID, a claim is used for a given feature. But in most cases, just a single claim is not enough to make the functionality work. Audience is part of a bigger picture that includes the use of the client_id, the aud, and the azp claim.

  • When a client is issued a token, it can always use that token to access itself. Therefore, a client is always its own audience. If a client’s tokens are intended to be used only by itself, the aud claim may be omitted.
  • token may specify multiple audiences. However, when a token has multiple audiences, it can be unclear which client originally requested it. To clarify this, tokens with multiple audiences include an additional claim: the azp (authorized party) claim. This claim contains the client_id of the client that requested the token.

Summary

When securing applications with OAuth, it is important to understand who is using each application and what permissions or authorization scopes are appropriate.

This authorization model can be enforced using the aud claim and OAuth scopes.