[Openid-specs-ab] Feedback requested: JWT library effort

Vladimir Dzhuvinov vladimir at connect2id.com
Mon Aug 28 08:10:36 UTC 2017


Hi Adam,

Client code and client developers are indeed the weak link in the whole
system.

Since 2012 we maintain a JOSE/JWT library and a separate SDK for
building OAuth 2.0 and OpenID Connect clients and servers. We actively
discourage developers from using the JWT library directory for ID token
validation. Even if you give developers a JWT library that is
cryptographically sound and compliant with the JWT spec, this is no
guarantee that the ID token validation will be implemented correctly and
according to the requirements of the specific OpenID Connect flow /
profile. What has worked best was to provide developers with an OpenID
Connect client abstraction for validating ID tokens where dealing with
the JWT specific stuff is completely hidden (including things like
OpenID provider key retrieval and caching), so developers need only
provide the following inputs:

1. An object with the OpenID provider details (endpoints).

2. An object with the OpenID client details (client_id, secret or JWKs,
etc).

3. The OpenID authentication request.

4. The OpenID authentication response and / or token response.



How to achieve this practically and with minimum effort?

Fortunately, the OpenID Foundation has created a Relying Party
certification program, which includes a test suite for OpenID clients,
and is platform / language / framework independent:

http://openid.net/certification/


Suggesting client library developers certify, or giving them with some
incentive to do so (e.g. when they register with Google) will probably
be the most efficient way to achieve the security you're looking for,
without having to maintain "compliant" libraries yourself for a variety
of platforms, etc.

In terms of innovation, this also seems like the best approach -
developers will be free to innovate, e.g. by adding support for new
frameworks, languages, platforms, etc. They just need to make sure their
client library becomes certified to be credible.

If you want to achieve particular security objectives, you could do that
by contributing to / extending the certification suite. The suite itself
is open source.


Vladimir


On 24/08/17 03:50, Adam Dawes via Openid-specs-ab wrote:
> Hi all,
>
> I have mentioned to some of you that Google is very interested in making it
> easy and secure for developers to do JWT/ID Token validation on their
> servers. We think resources like jwt.io and the many open source libraries
> have helped developers a lot with this process. But we are also concerned
> that there are still many ways to mess up validation and want to make it
> easy for developers to automatically do the right thing. I'm reaching out
> because we would like to partner with the Foundation and the Connect WG to
> build canonical libraries that gain wide adoption and which help drive
> greater adoption of federation.
>
> To drive this effort forward, I wanted to introduce a new PM on my team,
> Luke Camery. He's put together a spec
> <https://docs.google.com/document/d/1V5uE-aR6k5JYuQQ6Ylgj8t1F_HMS7DEMJ4AIRMyR9Ts/edit#>
> for
> the libraries.
>
> I'd like to invite the group to provide feedback and also see if it would
> be worthwhile to walk through this on an upcoming WG call. Also, we're also
> going to be looking for contractors to help us implement these requirements
> so if any of you are available or have recommendations, we would love to
> get those.
>
> Please let us know what you think.
>
> thanks,
> AD
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3711 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170828/dd277095/attachment.p7s>


More information about the Openid-specs-ab mailing list