Beyond the login screen - Part II

In Previous post, we reasoned around why transparency while collecting user data is important. In this part let us dig deeper into one of the Open Standards OpenID Connect and see how the standard gives flexibility and transparency around user data management.

The Familiar OAuth2 dance

OpenID Connect is built on top of OAuth2,

Before jumping on to technicalities of OpenID Connect, let us brush our memory on how we (The Users) are used to signing in with Google (The Identity Provider) to Meetup (The App).

Move 1: User goes to Meetup app and clicks on log in with Google

Move 2: Meetup app then asks Google to authenticate the user and share the basic profile of the User

Move 3: Google then asks the user to login

Move 4: On successful authentication of the user, Google now asks User if it is ok for them to share their basic profile with Meetup and User consents to Google to share their data to Meetup

Move 5: Google now shares an ephemeral Key to Meetup that can unlock the User's consented data

Move 6: Meetup uses the key to get Basic profile data.

What User Data?

At Move 2, Meetup knows that it only needs basic profile data like Name, email and profile picture to complete its user profile.

Why User Data?

At Move 4, Google asks the User's consent to share the data to Meetup explaining that this will be used as a profile.

Flexibility and Transparency

Now replace Google with your own Identity Provider, then you have achieved a new level of flexibility towards transparent data management.

Assume Meetup needs this new feature, that can show meetups nearby, So now Meetup app needs to know the postal code of the user, all Meetup app now needs to do is request for a new scope pincode along with basic_profile and now the Identity Provider would ask consent for the newly added scope to user.

Behind the scenes

If you know the dance, you can skip to Conclusion. If you want to learn the moves, continue reading

Move 1

User goes to Meetup app and clicks on log in with Google

In order for this to be possible,The App should register itself with the Identity Provider, by providing minimum the Name it wants its Users to see in Move 4 and a url for the Identity Provider to communicate the result to.

This is Client Registration. As a result of registration now the App gets an Id and a Secret.

Move 2

Meetup app then asks Google to authenticate the user and share the basic profile of the User

Now The app forms a request with its Id and registered Url and requests for a scope e.g. Basic Profile using response_type one of the three flows (Basic, Implicit or Hybrid) to receive the user's data

This is an Authentication Request.

Move 3

Google then asks the user to login

At this point The Identity Provider checks for the validity of client (id and registered url), and asks the user to login.

This is an Identity Provider doing its identity thing.

Move 4

Google now asks User if it is ok for them to share their basic profile with Meetup

On successful authentication, now Identity Provider shows the consent screen to the user describing the
what data the app needs and why.

This is Getting the user's consent

How user gets authenticated or consents is out of scope for the OpenID Connect standard.

Move 5

Google now shares an ephemeral Key to Meetup that can unlock the User's consented data

On successful authentication and receiving user's consent, Now Identity Provider has to share this with the App. How this information is shared to the app is decided by the response_type value provided by the app in Move 1

The end result of any flow (Basic, Implicit, Hybrid) is generating one or more of access_token refresh_token and id_token.

This is successful token response from token endpoint for Basic and Hybrid flows or authorize endpoint for Implicit flow.

Choosing flows

Move 6

Meetup uses the key to get Basic profile data.

Now the App can use this short lived access_token to get information about user.

This is User Info endpoint

The Questions we need to ask,

So Identity Provider can validate App and User, But How does the App know

• It is indeed The Identity Provider that authenticated the user and responded to it?
• How long since the user was last authenticated? Given all the SSO convenience going on?
• With which level of security (1FA or 2FA) the user was authenticated? Given the App deals with of course money, we need to have iron clad security don't we?

The Answer is id_token

This is what makes OpenID Connect different about OAuth2, It provides an Identity layer on top of the OAuth2 standard. It gives feedback to the App about the authenticated user.

You can think of id_token as digital secure identity card of the user. It is a JWT token signed by the Identity Provider's private key. The Public key is shared through keys endpoint

Conclusion

By abstracting away authentication and authorization data of the user we can achieve flexibility on how and when to collect the data there by building up a User Profile. The Identity Provider can define scopes, that allows an App to not only get user data but also to write user data through Scope Management.

And the standard gives you enough trust and confidence that the data is being exchanged between the App, User and Identity Provider in a secure and transparent manner.