[Openid-specs-ab] JWT Federations - Proof of concept implementation

Andreas Åkre Solberg andreas.solberg at uninett.no
Wed Aug 15 18:32:56 UTC 2018

I just completed a proof of concept of an OpenID Connect Client and a Provider establishing trust using JWT Federation.

Here is an OpenID Connect Client
(any username/password is accepted. username is sent as sub)

This client is not preregistrered with any providers, nor does it not have metadata for any providers. It takes a query string paramter of an OpenID Connect Provider to connect to. The client hosts its own metadata using WebFinger, and it is pointing to some third party trust issuers (federation) within its metadata.

The client is running an unmodified Node.js OpenID Client software by Filip Skokan / Auth0.
The only needed extra steps was to use a JWTFed enabled discovery function instead of the built in OpenID Discovery function, and add a simple co-loaded WebFinger server.

The code for the client is available here:

The corresponding OpenID Connect Provider is running an unmodified Node.js OpenID Provider by Filip Skokan / Auth0.
The only needed extra steps was adding a custom WebFinger server serving signed metadata, and providing the OIDC Server with a custom client store adapter. When the provider gets an incoming authentication request, it calls the adapter with a find(client_id), the adapter performs some magic with webfinger, and nesting through a chain of trust entities, before it returns proper client metadata including the client public key.

The code for the provider is available here:

Both the client and the provider is configured with edugain as a trust root, and no further configuration is needed in order for these two entities to participate in a federation involving thousands of entities.

In addition to the client and provider, a few entities issuing trust statements are involved in the flow. These are very simple Webfinger endpoints that signs statements about others. The code for these are available here:

I was surprised by how well this approach fits with the rest of the OpenID Connect standard and unmodified vanilla OIDC products.

The most severe obstacle I came across was the fact that I was enforced to use jwks_uri for the provider metadata. I would prefer if the OIDC federation specification denied the use of jwks_uri, which is a very weak point - reducing the whole trust chain to rely on the TLS trust root / cacerts. This problem goes beyond the software I used, as I see in the OIDC Discovery specification that jwks_uri is [required]. I’d suggest to move OIDC provider metadata into a separate spec, and let OIDC discovery be one of possible multiple alternative transports. The metadata spec should make jwks_uri optional, and add a property for embedding an jwks.

Andreas Åkre Solberg
Senior Technical Architect
UNINETT – https://uninett.no

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20180815/40d0a355/attachment.html>

More information about the Openid-specs-ab mailing list