Update on OpenID and OAuth

| | Comments (0) | TrackBacks (0)
OpenID and OAuth are undergoing a lot of work ATM, and it can be confusing to those that aren't in the thick of it to keep up w/ where things stand. Based on what I heard last week at IIW, where a lot of this work happens, I thought I'd put together an update in hopes that it helps.

After OpenID 2.0 was around for a while, Google and IINM Facebook proposed a new version of the standard called OpenID Connect. This version of the protocol uses OAuth on the front-channel to securely access an API on the back-channel to get user attributes. Around the same time, a need in Japan to provide higher levels of assurance (LOA) and secure interaction w/ Web APIs from mobile applications resulted in the creation of another derivative of the protocol called OpenID Artifact Binding (AB). Last fall at IIW, the authors of each of these vNext protocols started working to align their efforts. The combined spec was commonly referred to by the authors and other insiders as OpenID ABC (as in Artifact Binding + Connect). This harmonization was tricky though because OAuth 2, which they each depend on, wasn't done and the timeframes of the initial customer needing OpenID AB and funding its development might not allow for the work to wait till OAuth was ready.

As of last week, it looks like the stars are aligning and these two updates of OpenID will be merged. This result will be called OpenID Connect rather than OpenID 3.0, OpenID AB, or OpenID ABC. It also looks like OAuth will finish in time for OpenID Connect to normatively reference it, something that isn't allowed by the IETF (which governs that emerging standard) unless the spec has been officially ratified. If OpenID Connect finishes before OAuth 2, it will have to reference the latest draft (which hopefully won't happen). A draft of OpenID Connect is on tap for Julyish.

OAuth was conceived of and developed in an open community where it became increasingly popular. Because of concerns about intellectual property rights (IPR), however, many large organizations couldn't or wouldn't adopt it. For this reason, it was submitted to the IETF and an IPR regime was put in place to alleviate such concerns. Soon after, a security issue was found, and the community rallied to fix it. This update was also contributed to the IETF. Not long after, Microsoft created a RESTful token issuance protocol which they called OAuth WRAP. This protocol wasn't compatible w/ OAuth in anyway, but, to the chagrin of some in the OAuth community, used its brand. Unlike OAuth proper, WRAP didn't support signatures; it relied solely on transport security and didn't define a way to do security at the message level. Signatures were purported to be the Achilles' Heel of OAuth which tripped up many developers, so this change would make implementation simpler and adoption greater (its proponents said). As a result, it too was contributed to the IETF and formed the basis of OAuth 2.

Since then, support for signatures has been added and other ideas from OAuth proper have been fused together w/ WRAP. As the emerging standard grew, it was decided to break it apart into a core specification and other supporting ones. Some of supporting standards are JSON Web Tokens (JWT) which defines a way of representing security token in JSON (think WS-Security w/ curly braces). There are also specs for defining specific types of tokens, namely bearer and signed tokens. A supplementary profile defined by my colleague Brian Campbell specifies how a client should send a SAML assertion to an OAuth Authorization Server (AS) when it wants an access token in exchange. Currently, it is expected that the main specifications will be finalized in Julyish around the same time the draft of OpenID Connect will surface.

Tony Nadalon, who has been much more involved in this process than I have will be giving his update tomorrow at EIC, If you're here in Munich, don't miss that. (If he says anything contradictory to what I've written, I'll update this post.) In the meantime, if you read something that isn't accurate here, you have details to add, or if you have questions/comments, please let me know.