An authorization server issues an access token with issuer details which are exposed in a well-known API of that server. This server uses client authentication JWT tokens with clients configured. These JWT tokens are sent as a part of a request from clients to the authorization server and have one of the claim audience of authorization server with URL and port.

Should a well-known API have the same issuer URL (access token) details as the audience in (JWT), or the JWT audience can be a different URL with the port of the authorization server?

Payload of client authentication JWT


payload of access token JWT

  • I fail to see how this is connected to OIDC - JWT tokens are not OAuth 2.0 tokens to my best of knowledge. Then again, I am not an expert in this field apparently. Feb 11, 2023 at 18:17
  • OpenID Connect is builds on top of OAuth 2.0 and provides a simple identity layer on top of OAuth. In OpenID Connect, the authorization server issues ID Tokens as well as Access Tokens to the client. The ID Token is a JWT token that contains information about the authenticated user.
    – user890234
    Feb 11, 2023 at 18:33
  • I see. I think the audience is always "public" in that sense then. But I'm apparently not sure.. Feb 12, 2023 at 14:45
  • Your question isn't clear enough. After reading it multiple times, I'm able to understand that you are asking if the audience for the access token can be different. Audience can be actually empty if you don't care about for whom the access token is intended. When requesting the access token, you can ask IdP to put the client ID of the intended receiver. By default, IdP can also add client IDs of trusted clients unless configured. Lastly, audience is irrelevant to the well-known config. Well-known config is just about exposed endpoints and supported algorithms that your IdP supports.
    – defalt
    Feb 13, 2023 at 12:50
  • 1
    aud and iss are not related to each other. They are different.
    – defalt
    Feb 13, 2023 at 17:51

1 Answer 1


Both aud and iss identify participants in the authentication flow.

  • iss identifies the participant issuing a token, in your scenario the access token
  • aud identifies the participant(s) that may accept a token, in your scenario the JWT.

The identifier can be a URL but also an arbitrary string.

In your scenario, the participant is in both cases the authorization server: It accepts a JWT and issues an access token in exchange. Therefore you could use the same identifier for both.

But if your server had several authorization endpoints (one reachable from the internet, another reachable only from an intranet), you could equally represent them by different values for the aud claim, and use yet another value in the iss claim. In other words: You have some freedom here because, as defalt pointed out, the two claims are not related to each other.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .