Hi Devmego99,
I think you are asking "Is it better for a sending party to retrieve his JWT from a central authority, or to generate the JWT directly?" And if that's the question, then the answer is: it depends on how you would like to manage your keys and secrets.
Let me make some background comments first.
Applications can use signed JWT to authenticate. A requester can send a JWT to a receiver. The receiver can check the signature, and then if the signature verifies, the receiver can trust the contents of the JWT (like the sub, aud, and iss claims). The receiver can then make decisions based on those verified contents.
How the sender generates or obtains the JWT is not so important in all of that. It does affect what the receiver needs to trust. Often there is a 3rd party Identity Provider in an enterprise that is the central trusted authority. If a JWT is signed by that provider, then every other actor in the system trusts it. Usually this "trust" means that verifying parties will retrieve verifying keys from a JWKS endpoint exposed by the Identity provider. The verifying party will use that JWKS URL with their own JWT libraries or etc., and this means they'll implicitly retrieve keys from that endpoint. The JWKS serves as a key publication endpoint. It's a "hub and spoke" model. The central signing authority is the "hub" and all the verifying parties are "spokes" that connect into that endpoint.
But in some cases people use point-to-point trust. In other words, generate a signing key, give it to the sender. Give the verifying key to the receiver. Now when the sender "self signs" a JWT, the receiver can verify that signature with the "verifying key". This works the same way as the "Trusted central authority", except now you have to manage the keys in both the sender and receiver. If you need to revoke the key of the sender, then you need to update all the potential receivers who have the verifying key. In a complex enterprise, it's sometimes easier to have a central signing authority.
BTW, you could use Apigee as the central authority. You could configure an Apigee API Proxy to manage keys and expose a JWKS endpoint. Here's a repo and screencast that shows that.
Sooooo, getting back to your question. Is it better for a sending party to retrieve his JWT from a central authority, or to generate the JWT directly? I guess it depends on how you would like to manage your keys and secrets.
Keep in mind that even if there is a central authority that issues JWT.... still the "sending parties" need to authenticate to THAT. So the sender will need a key or some credential to connect to that thing (that IDP) in order to ask for a signed JWT. Using a central IdP does not remove the need for authenticating actors in the system to possess keys. They still need keys. But there is an indirection - they use a key to identify themselves to the IdP, and the IdP issues the JWT.
The alternative is to have the sender possess the signing key directly. In either case the sending party needs to have some "secret" or key, in. order to participate in an authenticated communication exchange.
LinkedIn
Twitter
