We at Ping have participated in the standards process to make OpenID Connect happen, working with some crazy smart contributors. We cast our vote last week within the OpenID Foundation in support of the standard.  And now that Connect is ratified, we can't wait to get out there and contribute to a very quickly growing ecosystem (click here to see our OpenID Connect product support).

 

If you are not familiar with OpenID Connect, you can read the specs at http://openid.net/connect, or you could download one of our whitepapers. They will tell you that OpenID Connect is an identity layer built on top of OAuth 2.0, and they will explain how OpenID Connect profiles specific OAuth scopes and response types to create several patterns that let you send an assertion (IDtoken) about the owner of a delegated authorization token (access token) to the client that requested the token. 

 

If the above description doesn't excite you as an identity architect, it should, because in my opinion OpenID Connect has the potential to address some of the most critical barriers to growth and success in this industry.

 

Existing processes of enabling an application for federation are quick, but not perfect. In order to federate with your partners, you must often force them to take steps to be as sophisticated an entity in the identity world as you are. This often involves education, and has in the past been costly for that partner, although these days IDaaS offerings like PingOne help with that burden.

 

But what if you could alleviate much of your partner's burden, while gaining better control yourself? That is the promise of OpenID Connect. Some other critical points: 

 

1) Anyone can quickly and easily become a relying party

 

OpenID Connect provides a relying party design pattern that uses REST and JSON, and can work on any platform. This design pattern can be as simple as executing one web request and a REST call to get a simple JSON IDtoken, or it can scale up to much more complex patterns to perform higher level of assurance transactions, including adding encryption, signing, and complex communication of requirements between the Relying Party and the Identity Provider.

 

2) OpenID Addresses the connection lifecycle, including trust establishment

 

Connect includes all the pieces for a fully automated connection to come to life, dynamically learn what algorithms to use, register itself uniquely with the infrastructure, and then "just work".   

 

 3) It addresses mobile and web identity

 

OpenID Connect contains design patterns for web sites, for native code, and even for embedded widgets. The security patterns differ in order to mitigate various attacks, and the architectural reasons for those different security patterns can be debated and documented.

 

These points combine to offer architects some powerful new tools. As a result, we as an industry get to make new steps in our world, addressing existing problems of scale, adoption, and automation. 

 

The future is bright and real. Time to have fun!

 

---