What do 'Scope' and 'Audience' mean?

I’m looking for guidelines or best practices around how to leverage these two JWT fields, either in terms of generic OAUTH2 guidelines or Okta-specific guidelines. From my reading, I am thinking of them as:

  • ‘Audience’ pertains to the Services that would receive and handle a JWT. If they don’t consider themselves the right ‘Audience’ they should not perform the request.

  • ‘Scope’ pertains to the underlying data resources, maybe more like a traditional entitlement or permission but mainly a granularity.

I could intuitively think of Scopes nesting within each other but not Audiences. Problem is, Scope supports a list of scopes, but Audience seems to be a scalar. Given these definitions, I’d kind of prefer the opposite. Which suggests that perhaps I’m not really thinking about them correctly, or at least not aligned to their original intent.

Is there any discussion or set of examples that clarify how these claims are designed to be used?

Based on the OIDC/OAuth 2.0 overview [https://developer.okta.com/docs/reference/api/oidc/#claims]

aud - Identifies the audience (resource URI or server) that this access token is intended for.
scp - Array of scopes that are granted to this access token.

The claim aud or Audience extends from the JWT specification defined under RFC-7519. It essentially is a way for the consuming party to validate if a particular JWT is meant for them or not. According to the specification it can be an array.

The claim scope extends from the OAuth specification discussed under RFC-6749. It is essentially a way of scoping Access Token to a limited set of claims or user data. For example, you don’t want a 3rd party client querying just about anything with an access token they obtained using the OAuth2 flow. This is a way of limiting the scope of their access token to a set of claims.

Hope this helps!

1 Like

Thanks, that does help a bit; glad to know that audience can be a list.

I found some nice examples of scopes here: https://oauth.net/2/scope/

So for example, I could imagine multiple Fitbit Microservices (‘audiences’) with access to biometric data, with this you could granularly control the combinations of Services with ‘Heartrate’ access.