Behind That 'Login with Google' Button💡

Have you ever logged into an app using your Google or Facebook account? That seamless experience is powered by OAuth 2.0 and OpenID Connect (OIDC). 
There's also a lot of conflicting information out there. The goal here is to explain how these standards work. Let's get started.

In the Stone Age days of the Internet, sharing information between services was easy. You simply gave your username and password for one service to another so they could log into your account and grab whatever information they wanted. However, you should never be required to share your username and password, your credentials, to another service. There's no guarantee that an organization will keep your credentials safe or guarantee their service won't access more of your personal information than necessary. It might sound crazy, but some applications still try to get away with this. 

What is OAuth 2.0

We have agreed upon standards to securely allow one service to access data from another. OAuth 2.0 is a security standard where you give one application permission to access your data in another application. You can essentially give one app a key that gives them specific permission to access your data or do things on your behalf in another application. The steps to grant permission or consent are often referred to as authorization or delegated authorization. What's more, you can take back that key whenever you wish. Awesome!

As an example, let's say you've discovered a website named "Dad Jokes Daily" and created an account to have it send a Dad Joke as a text message every day to your phone. You love it so much that you want to share this site with everyone you've ever met online. Who wouldn't want to read a terrible Dad Joke every day, am I right? However, writing an email to every person in your contacts list sounds like a lot of work, and if you're like me, you'll go to great lengths to avoid anything that smells like work. Fortunately, "Dad Jokes Daily" has a feature to invite your friends.
 
Let's clear out some terminologies before going further.

1. Resource Owner - That's you. You are the owner of your identity, your data, and any actions that can be performed with your accounts. 
2. Client - This is the application in our example, "Dad Jokes Daily," that wants to access data or perform actions on behalf of you, the resource owner. 
3. Authorization Server - This is the application that knows the resource owner, where the resource owner already has an account.  Resource Server - The API or service the client wants to use on behalf of the resource owner. 
4. Redirect URI - URL the Authorization Server will redirect the resource owner back to after granting permission to the client. This is sometimes referred to as the callback URL. 
5. Response Type - A type of information the client expects to receive. The most common response type is "code," where the client expects to receive an authorization code. 
6. Scope - Granular permissions the client wants, such as access to data or to perform actions. 
7. Consent - When the Authorization Server takes the Scopes the client is requesting and verifies with the resource owner whether or not they want to give the client permission. 
8. Client ID - An ID used to identify the client with the Authorization Server. 
9. Client secret - A secret password that only the client and the Authorization Server know. This allows them to securely share information privately behind the scenes. 
10. Authorization Code - A short-lived, temporary code the Authorization Server sends back to the client. 
11. Access token - The key client will use from that point forward to communicate with the Resource Server. 

Now that we have some of the OAuth 2.0 vocabulary handy, let's revisit our example with a closer look at what's going on throughout the OAuth flow.

1. You, (Resource Owner), want to allow "Dad Jokes Daily" (Client), to access your contacts so they can send invitations to all your friends. 
2. The client redirects your browser to the Authorization Server and includes with the request the client ID, redirect URI, response type, and one or more scopes it needs. 
3. The Authorization Server verifies who you are and, if necessary, prompts for a login. 
4. The Authorization Server then presents you with a form based on the Scopes requested by the client, and you have the opportunity to grant or deny permission. 
5. The Authorization Server redirects back to the client using the redirect URI, along with a temporary authorization code. 
6. The client then contacts the Authorization Server directly (it does not use the resource owner's browser) and securely sends its client ID, client secret, and authorization code. 
7. The Authorization Server verifies the data and responds with an access token. The access token is a value the client doesn't understand. As far as the client is concerned, the access token is just a string of gibberish.
8. The client can use the access token to send requests to the Resource Server. The client is like, "Here's an access token, I would like the contacts associated with the resource owner of this token." 
9. The Resource Server verifies the access token, and if valid, responds with the contacts requested. 

"Dad Jokes Daily" can now send emails to everyone you know, and you'll be the most popular person ever. OAuth for the win! 

Before all this, the client and the Authorization Server established a working relationship. The Authorization Server generated a client ID and client secret and gave them to the client to use for all future exchanges. This is how the Authorization Server can verify the client. 

The OAuth flow in this example is made of visible steps to grant consent as well as some invisible state, where the two services agree on a secure way of exchanging information. 

---

What is OpenID Connect (OIDC)?

Now, let's talk about OpenID Connect. OIDC is a thin layer that sits on top of OAuth 2.0 that adds functionality to get profile information about the person who is logged in. Instead of a key, OIDC is like giving the client application a badge. The badge not only gives the client specific permissions but also provides some basic information about who you are.

• OAuth enables authorization (one app accessing another on your behalf).
• OIDC enables authentication (verifying who you are) and provides identity information about the resource owner.

When an Authorization Server supports OIDC, it is called an Identity Provider since it provides information about the resource owner back to the client. OpenID Connect enables scenarios where one login can be used across multiple applications, also known as Single Sign-On or SSO.
One way you might think of OIDC is kind of like using an ATM. The ATM is the client. Its job is to access data such as your bank balance and perform banking transactions. Your bank card is the token that's issued by the bank. It not only gives the ATM access to your account (the authorization), but it also has some basic information about who you are, your identity, such as your name and authentication information such as when the card expires, who issued the card, and the bank's phone number. An ATM can't work without the underlying bank infrastructure.
Similarly, OIDC sits on top of OAuth and cannot work without the underlying OAuth framework. The OpenID Connect flow looks the same as OAuth. The only difference is, that a specific scope of OpenID is used. This lets the Authorization Server know this will be an OpenID Connect exchange. The Authorization Server goes through all the same steps and the client receives an access token and an ID token. The ID token is a specifically formatted string of characters known as a JSON Web Token or JWT. A JWT may look like gibberish to you and me, but the client can extract information embedded in the JWT, such as your ID, name when you logged in, and the ID token's expiration, and it can tell if anyone has tried to tamper with the JWT. The data inside the ID token are called claims. 

Well, that's it, folks. That is OAuth and OIDC in a nutshell. These two work together to securely authorize access to resources and authenticate users. Whether you're logging into an app with your social media account or using Single Sign-On (SSO) at work, these technologies are the backbone of modern digital identity.

Sources:

• https://youtu.be/996OiexHze0?si=x7nUEYgFNNCNUXYq
• https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
• https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce