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
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 asksbasic 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
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
User
if it is ok for them to share theirbasic profile
withMeetup
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
Meetup
that can unlock theUser'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 getBasic 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.
Top comments (0)