3 ms·
AzureAD is built around OIDC. Yes, the tokens use JWT but that can be treated as an implementation detail. The mechanism here is OIDC, not specifically JWT. The
by hnbad 2y ago
AzureAD is built around OIDC. Yes, the tokens use JWT but that can be treated as an implementation detail. The mechanism here is OIDC, not specifically JWT. The tokens can be treated as mostly opaque.
Also in that case you aren't using JWTs for authentication, AzureAD is and you're integrating with it. And as I said, you're integrating with it via OIDC.
- whizzter 2y agoopaque apart from that you should verify that the JWT token is issued by a trusted party and fulfills claims that your service requires? :P (Unless those parts are handled by a library you've configured to check this).
- hnbad 2y agoThe point is that when logging in with AzureAD your app needs to talk to AzureAD using OIDC but JWT is an implementation detail of that specifically and there's no reason this means you need to or should be using JWT throughout the rest of your architecture. If you're using AzureAD for IAM, you're not "using JWT for authentication tokens", you're using AzureAD. This isn't what the article is about. The article is about building your own services that generate and process JWTs. And yeah, if you use an OIDC API you likely use an OIDC library instead of rolling your own. So as far as your own code is concerned the token is entirely opaque.
- osigurdson 2y agoWouldn't an app normally at least need to look at some claims in the jwt (email for example)? Otherwise, how do you identify the user?
- hnbad 2y agoBy using the token to access the userinfo endpoint of the OIDC API? Yes, some info is encoded in the token already but that's why OIDC includes that endpoint unlike OAuth2 (which was authorization only even if it was often used for authentication).