From the course: Web Security: OAuth and OpenID Connect (2019)

Extending OAuth 2.0 with OpenID Connect

From the course: Web Security: OAuth and OpenID Connect (2019)

Start my 1-month free trial

Extending OAuth 2.0 with OpenID Connect

“

- [Instructor] Now let's talk OpenID Connect, or OIDC. At first glance, OIDC looks nothing like OAuth. Instead of a loose agreement, it has a rigid structure. Instead of arbitrary tokens, it specifically defines both the format and the content of those tokens. In fact, most people think OAuth and OIDC are competing specifications. If you look closer, you'll realize that's not the case at all. Instead of OIDC being in conflict with OAuth, you'll see that it's just another extension. But in fact, it's one of the most widely implemented and used extension because it gives us tool for single sign-on and profile sharing. Of their numerous differences, there are three main ones that we care about in relation to this course. First, OIDC adds another type of token, the ID token. Unlike OAuth tokens in general, this one must be a JWT, and within that has specific naming requirements and contents that must be there. In vast majority of cases, this is the user's profile information. Next, it adds another endpoint, the user info endpoint. You use this to retrieve user info. It's kind of tricky like that. Now, this will generally retrieve the same user information which was available in the ID token itself. Therefore, if our applications trust the system that issued the token, we know who signed in when and can use that to create a profile on our end. It simplifies creating a new user account by not forcing them to retype profile information. Finally, OpenID Connect only supports a subset of the OAuth grant types. We'll cover these grant types in more detail later, but you'll soon see how these are the only ones which are both user oriented and considered very secure. Now, if you look at OIDC more closely, you should see that it's not in competition with OAuth at all, but just a structured pattern on top of the existing framework. And most likely, you're using OpenID connect right now. If you signed in to LinkedIn Learning with your LinkedIn account, you saw it. You clicked the log in button. Your browser opened a window for you to log in to LinkedIn. Then you did, the window closed, and you were redirected back. As a result, you now have a full profile based on your LinkedIn data. You never had to share your credentials or retype that information. How easy is that?

Contents