Differences between audience, issuer, and client terms in JWT, OAuth and OIDC [closed]

Question

"The half of knowledge is to say I don't know when you don't" proverb

Every time I try to keep my knowledge about these terms clear and correct. However, over the development of new projects and acquiring new knowledge (SaaS, Multi-tenancy, 2Step Verification, IdPs, SSO ), I feel like I still do not understand them correctly. Any one can give a simple and efficient explanation?

I am an ASP.NET developer.

Answer 1

I like that quote, so, this is some answer. Let's say we have a jwt like this

{
   // ...Some other claim
   iss: "MyKnowledgeCenter.com",
   aud: "Abu.questioning.com",
   // ...Some more other claims
}

First thing is about issuer, which represent as iss. This indicate that where the whole Jwt you have come from. For ex: We have a request for access token at https://abu.Identity.com, but the issuer could be MyKnowledgeCenter.com, or https://abu.Identity.com or anything else. We have freedom to just indicate those as we code the identity centralize server ourself.

In short, iss is just a Jwt claim that have nothing difference from other, except it's meaning is to indicate that this jwt was self-declared that it came from an issuer that called MyKnowledgeCenter.com from this example.

About audience, again, it's a claim in a Jwt, that must be set, represented for one or a collection of which services that the Jwt itself intended to use for.

I love example: I have 2 microservices is Catalog and UserProfile, that require client to have a Jwt was issued at MyKnowledgeCenter.com to access their resources. If on those 2, validating on audience is required (as we can set it), then, even if the sign is valid, but aud was lack of Catalog, client cannot access Catalog microservice resources. The same applied for all others.

Okay, so where's the client ?

Well, that's indicate something as setting but not re-presented in the Jwt.

Imagine, we have a centralize authentication server, but we only intend to serve our own services, and clients. Not the whole Internet world, right ?

So, specifying those specific clients would benefit, as I just want to serve an app on iOs, another from android word and a website of our own. Therefore, 3 clients. If any request that came from any other clients that have informations doesn't match one of those 3, we rejected them immediately.

Simple enough ?

Answer 2

I believe this explanation is simpler:

• Audience: What is the target of this token. In other words which services, apis, products should accept this token as access token for the service. They may be many valid tokens in the world, but not all of those tokens have been granted by the user (or resource owner) to allow access to the resources saved in the product services. A token valid for Google drive should not be accepted for GMail, even if both of them have the same issuer, they’ll have different audiences. Why? Because an user may have given access to a 3rd party service to access their GMail, but not their documents in Drive.

• Issuer: Who created the token. This can be verified by using the well-known openid configuration endpoint and public keys. Since issuers are tied to DNS entries/url paths, each issuer must be unique. Two services can’t both be the same issuer. Tokens issued by Google will have a different issuer than the ones issued by Authress.