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.
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
Move 1: User goes to
Meetup app and clicks on log in with
Meetup app then asks
basic profile of the User
user to login
Move 4: On successful authentication of the
User if it is ok for them to share their
basic profile with
User consents to
Meetup that can unlock the
User's consented data
Meetup uses the key to get
Basic profile data.
At Move 2,
Meetup knows that it only needs
basic profile data like
profile picture to complete its user profile.
At Move 4,
User's consent to share the data to
Meetup explaining that this will be used as a profile.
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.
If you know the dance, you can skip to Conclusion. If you want to learn the moves, continue reading
User goes to
Meetupapp and clicks on log in with
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.
Meetupapp then asks
basic profileof 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.
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.
Userif it is ok for them to share their
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.
Meetupthat can unlock the
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
Meetupuses the key to get
Now the App can use this short lived
access_token to get information about user.
This is User Info endpoint
So Identity Provider can validate App and User, But How does the App know
- It is indeed
The Identity Providerthat 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?
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.
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.