Identity, Authentication + OAuth = OpenID Connect

Identity, Authentication + OAuth = OpenID Connect

Hi, I am Nat Sakimura, the chairman of the OpenID Foundation, and a senior Researcher at Nomura Research Institute. Today, I want to talk a bit about the new identity protocol we are building: OpenID Connect, an identity layer on top of Oauth 2.0. But before diving into it, I need to define “identity”, which we often talk vaguely. Luckily, ITU-T and ISO has defined it in the IT context for us: it is “Set of attributes related to an entity” To understand this definition, we have to understand entity identity model. Entity is like us, human being, or machines, services, whatever. But we do not perceive entities directly, but indirectly through various attributes about the entity, like he has blond hair, wears glasses, 6 feet 5 inches tall, etc. and we want to express ourselves depending on who we are talking to by controlling what set of attributes, identity, we show. So, your identity to your friends and identity to your boss are naturally different so we have multiple identities Men are said to have typically a few identities, like Work, Husband, Father and women have a lot more We pick and choose which identity we use depending on the context The same holds for web sites. You want to use different identities depending on the sites you go to get better service. That’s the identity layer, and with OpenID Connect, we have chosen to build it over OAuth 2.0. This is often called “Authentication” as well. But you may ask “Why not just OAuth? Facebook does the same with OAuth do not they? Well, not quite. OAuth itself has no notion of identity. OAuth is an access granting protocol, also known as delegation. Alice granting an access to Betty’s profile data to Cindy does not mean that Alice is Betty nor Cindy is Betty. Unfortunately though, many services make this mistake and make it easy for a service to impersonate a user. Facebook’s case is different. They do not use OAuth for authentication as is, , but have built an extension called signed request, which is essentially the same as the OpenID Connect’s ID_token, except for the fact that it works only with facebook as the identity identity provider, and the signature format is proprietary while OpenID Connect works with multiple IdPs and uses IETF’s JSON Web Signature standard. In essence, what it does is to provide the web sites “Who got authenticated”, “Where, When and How it was”, “What attributes he want to give to you and Why” All of these defined in an interoperable manner — that is OpenID Connect. It is Interoperable Simple & mobile friendly, secure and flexible To be interoperable, we have to define a standard way of requesting and responding claims. So we have defined standard scopes, a method to ask for more granular claims, ID Token and UserInfo endpoint from which you can get the attributes as well as the translated tokens. It’s also very simple. It is JSON based, REST friendly, in simplest cases, it’s just copy and paste to implement a simple relying party and mobile and that’s friendly because that was an explicit design principle and thanks to OAuth 2. Its security model can scale all the way up to extremely secure, spanning from ISO 29115 Level of Assurance 1 to 4 leveraging on crypto and other techniques. It’s also very flexible. You can make a granular request through JSON based request object, which makes data minimization easy. To return the claims, you have the choice of aggregated and distributed claims with different privacy characteristics. OpenID Connect not only supports large identity providers, but you can actually have your own identity providers. For example, you can choose to use a dedicated identity provider on your phone. Current status of the specs are that they are waiting for some underpinnings such as JOSE specs and webfinger go final. Once that is done, we can finalize OpenID Connect and put it to the final membership vote. In the meantime, people are implementing current draft. Right now, 14 solutions are performing interops encompassing over 120 feature tests. So, start Building OpenID Now!

26 thoughts on “Identity, Authentication + OAuth = OpenID Connect

  1. Mr Sakimura, firstly thank you for the short video it made me understand much, secondly thank God you have a nice voice because I think I'm the only man that can hear your voice speaking about OIC when I sleep… At my MSc in Digital Systems Security we had a semester project for building a SSO platform with OIC… Until I understand what OIC does I've seen this video so many times so maybe 100 of the 53,5K views are mine… Good night "Today I want to talk a bit about…"

  2. Can you please make a video on how to use open id in node. authentication server and resource server implementations. Thanks Nice Video.

  3. Great explanation. So if I've understood correctly, If I have my own authorization server I should use oAuth2 access_token just to make API calls on behalf the user, eg. upload a post, upload a comment, remove a comment, etc. and I should use the OpenID connect id_token and/or the user endpoints it provides when I need to gather info about the user so I can be certain that the user is who he claims to be?

    I think I understand the difference between authorization and authentication but could you elaborate and give some examples? I mean: I don't need to verify that the user is X to e.g. call the API on his behalf and submit a post, that would be an example of delegated authorization right? Could you give examples of situations where I need to know who the user is and I can't delegate the authorization?

Leave a Reply

Your email address will not be published. Required fields are marked *