Skip to main content

Posts

Featured

Holding OIDC's narrative up to the light

OpenID Connect's (OIDC) stated aim is to provide the authentication neglected by OAuth. Yet I find some of its specification hard to reconcile with that narrative. For example, here are two of the claims OIDC standardises for the ID token. Their description puzzle me, especially when placed side by side: audREQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. … azpOPTIONAL. Authorized party - the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party. This Claim is only needed when the ID Token has a single audience value and that audience is different than the authorized party. … The Relying Party (RP) is the application that needs the user's identity information and hence takes the initiative for the OIDC dance. That means that it is also the entity that will receiv…

Latest Posts

OAuth is DAC. What do you do for MAC?

tl;dr: OAuth 2.0

Externalising the Security Token Service and Identity Provider

Problems with Basic Authentication for REST services

Bearer tokens are susceptible to theft and what you can do about it

In the (back)end, JWT is all that matters

Protect your REST APIs with JWT tokens

API gates and fences

Technology stack for a static web site