Beyond the login screen - Part II
Tags: security, transparency, openidconnect, dataprivacy
Published: 2018-03-12 03:03:45

---
title: Beyond the login screen - Part II
published: true
description: What OpenID Connect brings to the table
tags: #security,#transparency,#OpenIDConnect,#dataprivacy
cover_image: https://thepracticaldev.s3.amazonaws.com/i/qilhl5z77k9vnql942cr.jpeg
---

In [Previous](https://dev.to/shyamala_u/beyond-the-login-screen---part-i--29g3) 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,

<img src="https://thepracticaldev.s3.amazonaws.com/i/q6qv6y3adoe6zwakir2n.png"/>

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](#m1):** User goes to `Meetup` app and clicks on log in with `Google`

**[Move 2](#m2):** `Meetup` app then asks `Google` to authenticate the user and share the `basic profile` of the User

**[Move 3](#m3):** `Google` then asks the `user` to login

**[Move 4](#m4):** 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](#m5):** `Google` now shares an ephemeral Key to `Meetup` that can unlock the `User's` **consented** data  

**[Move 6](#m6):** `Meetup` uses the key to get `Basic profile` data.

## What User Data?

At [Move 2](#m2), `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](#m4), `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](#conclusion). If you want to learn the moves, continue reading

### Move 1<a name="m1"></a>

> 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](#m4) and a url for the Identity Provider to communicate the result to.

This is [Client Registration](https://openid.net/specs/openid-connect-registration-1_0.html). As a result of registration now the App gets an Id and a Secret.

### Move 2<a name="m2"></a>

> `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](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest).

### Move 3<a name="m3"></a>

> `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<a name="m4"></a>

> `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<a name="m5"></a>

> `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](#m1)

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](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) from [token endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint) for Basic and Hybrid flows or [authorize endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) for Implicit flow.

#### Choosing flows

<img src="https://thepracticaldev.s3.amazonaws.com/i/kv19qcqfwahq3q8nwmpy.png"/>

### Move 6<a name="m6"></a>

> `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](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo)

### The Questions we need to ask,

<img src="https://thepracticaldev.s3.amazonaws.com/i/u60yc2chlby6tsiphflz.png"/>

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.

<img src="https://thepracticaldev.s3.amazonaws.com/i/75gty0dmvj8zyafmb1kj.png"/>

You can think of [id_token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) as digital secure identity card of the user. It is a [JWT](https://jwt.io) token signed by the `Identity Provider's` private key. The Public key is shared through [keys endpoint](https://tools.ietf.org/html/rfc7517)

### Conclusion<a name="conclusion"></a>

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.