Series Introduction
This series aims to clearly explain the concepts of OAuth and OpenID Connect, as briefly as possible.
OAuth
Before I give you a standard definition for OAuth let's define what OAuth is not:
- OAuth is NOT authentication
- OAuth does not provide the identity of a user
OAuth is for authorization. For instance, let's say a third party application would like to access your Facebook profile data. Well, you can do exactly that using OAuth.
Let me illustrate this with a simplified diagram:
1 . The OAuth flow starts with the user (Resource Owner) being re-directed to the login page on the Authorization Server (Facebook, in our case). The user then enters their credentials to authenticate.
2 . After successful authentication, the Authorization Server returns an access token to the Client Application.
3 . The Client Application then uses the access token to retrieve the Protected Resource (Facebook profile).
The access token is meant to be used by the Protected Resource only. But it is often incorrectly used by the Client Application to identify the user, as an access token can sometimes contain user data.
So how do we provide the identity of the user to the Client Application in a reliable way?
That's where OpenID Connect comes in.
OpenID Connect
OpenID Connect (OIDC) is not a new protocol. It just extends OAuth by adding an identity layer on top of it. With OIDC, the client receives an ID token, in addition to the access token, at the end of the OAuth flow.
The ID token contains details about the authentication event and optionally user information. OIDC also adds a couple of useful endpoints to OAuth, which can be used to retrieve user information and manage session.
Next...
We will look at how OIDC provides authentication and user data to the client application
References:
Top comments (0)