Open ID Connect Certification: The news from the trenches – Google

OpenID Connect Certification: the view from the trenches

Wednesday 1H

Convener: Roshi Chandrashekhar & William Denniss

Notes-taker(s): William Denniss

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

OpenIDConnect Certification: The View From The Trenches

1. A general idea of where we started -- even though we helped write the spec, and we generally believed that the amount of work required to comply with the spec would be somewhat trivial, our bleeding-edge implementation with active users led to many challenges.

1. Backwards-incompatible changes like changing the issuer and adding “nonce” to id-tokens meant that we’d run into issues with clients who relied on our existing behavior. This can be solved by versioning our endpoints and supporting both the non-spec-compliant and compliant ones. However, it still leads to tricky issues like this: http://stackoverflow.com/questions/29916637/validating-google-oauth-id-token-received-from-oauth2-v4-token

2. Speaking of validation, there are a number of client libraries that still only expect the OLD Google issuer, even though the spec had an exception for Google’s issuer and stated that developers should handle both issuers that started with the schema and that did not. [1]

3. Discovery Document versioning - Since it’s hard-coded, there isn’t a way to version this. So we relied on http://stackoverflow.com/questions/29830503/google-is-updating-their-openid-connect-implementation-to-be-fully-spec-complian/29830504#29830504 caching - The general cache time for static documents like this one was 7 days, and we needed to be sure we could bring that down to ensure that anybody who saw a problem could report it quickly enough for us to point them to either StackOverflow or roll back.

4. Endpoints that may be out of scope of just OpenIDConnect Spec Compliance Providing spec-compliant claim names at TokenInfo Supporting spec compliant issuer values for ID Tokens issued as a result of assertions

There was an interesting discussion that followed about best practices while working towards spec compliance.

Link to Google.doc: https://docs.google.com/document/d/1hUPY2PCYJpeT5ocWDz5PvLvkgrKLdQ53pJYWLoKuE54/edit#