 Hey, have you ever tried to learn about OAuth and OpenID Connect, but became overwhelmed by all the strange terminology and jargon? There's also a lot of conflicting information out there, which can be really frustrating. The goal for this video is to explain how these standards work using simplified, easy-to-understand illustrations. And I hope we have a lot of fun. 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. Yikes! 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. Today, we have agreed upon standards to securely allow one service to access data from another. The first standard we need to cover is OAuth. OAuth 2.0 is a security standard where you give one application permission to access your data in another application. Instead of giving them your username and password, 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 even delegated authorization. You authorize one application to access your data or use features in another application on your behalf, without giving them your password. 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 TerriblePunOfTheDay and create an account to have it send an awful pun joke as a text message every day to your phone. You love it so much, you want to share this site with everyone you've ever met online. Who wouldn't want to read a bad pun 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. So here's you. Good thing, TerriblePunOfTheDay has a feature to invite your friends. The first step is to choose your email provider, and when you click on your email provider, you are redirected to your email service. Your email service then checks to see if you are currently logged in. If not, you get a prompt to log in. Whether you log in, or if you already have an active login session, you'll be presented with a question similar to, do you want to give TerriblePunOfTheDay access to your contacts? Assuming you haven't changed your mind, you click Allow. You are redirected back to the TerriblePunOfTheDay, and the application can now read your contacts, and that's the only thing it can do. TerriblePunOfTheDay can now send emails to everyone you know, and you'll be the most popular person forever. Oauth for the win. You've just stepped through what is commonly referred to as an oauth flow. The oauth flow in this example is made of visible steps to grant consent, as well as some invisible steps where the two services agree on a secure way of exchanging information. The previous TerriblePunOfTheDay example uses the most common oauth 2.0 flow known as the AuthorizationCode flow. Now before we dive into more details on what oauth is doing, let's map some of the oauth terminologies. Resource Owner. That's you. You are the owner of your identity, your data, and any actions that can be performed with your accounts. The client is the application, in our example TerriblePunOfTheDay, that wants to access data or perform actions on behalf of you, the Resource Owner. The Authorization Server is the application that knows the Resource Owner, where the Resource Owner already has an account. The Resource Server is the application programming interface, or API, or service the client wants to use on behalf of the Resource Owner. Sometimes the Authorization Server and the Resource Server are the same server. However, there are cases where they will not be the same server, or even part of the same organization. For example, the Authorization Server might be a third party service the Resource Server trusts. The Redirect URI. This is the 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. Response Type. The type of information the client expects to receive, the most common response type is Code, where the client expects to receive an Authorization Code. Scope. These are the granular permissions the client wants, such as access to data, or to perform actions. Consent. 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. Client ID. This ID is used to identify the client with the Authorization Server. There's also a client secret. This is a secret password that only the client and the Authorization Server know. This allows them to securely share information privately behind the scenes. Authorization Code. This is a short lived temporary code the Authorization Server sends back to the client. The client then privately sends the Authorization Code back to the Authorization Server along with the client secret in exchange for an access token. An access token is the key the client will use from that point forward to communicate with the Resource Server. This is like a key or a key card that gives the client permission to request data or perform actions with the Resource Server on your behalf. 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. You, the Resource Owner, want to allow terrible pun of the day, the client, to access your contacts so that they can send invitations to all your friends. The client redirects your browser to the Authorization Server. It includes with the request, the client ID, redirect URI, response type, and one or more scopes it needs. The Authorization Server verifies who you are and if necessary prompts for a login. The Authorization Server then presents you with a consent form based on the scopes requested by the client and you have the opportunity to grant or deny permission. The Authorization Server redirects back to the client using the redirect URI along with a temporary authorization code. 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 the authorization code. 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. However, 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. The Resource Server verifies the access token and if valid, responds with the contacts requested. It's also important to note that long before you gave terrible pun of the day permission to access your contacts, the client and the Authorization Server established a working relationship. The Authorization Server generated a client ID and client secret, sometimes called the app ID and app secret, and gave them to the client to use for all future OAuth exchanges. As the name implies, the client secret must be kept secret so that only the client and the Authorization Server know what it is. This is how the Authorization Server can verify the client. Now, let's talk about OpenID Connect. OAuth 2.0 is designed only for authorization, for granting access to data and features from one application to another. OAuth is like giving an application, the client, a key. That key is useful, but it doesn't tell the client who you are or anything about you. OpenID Connect, sometimes referred to as OIDC, is a thin layer that sits on top of OAuth 2.0 that adds functionality around login and 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, it also provides some basic information about who you are. Where OAuth enables authorization from one app to another, OIDC enables a client to establish a login session, often referred to as authentication, as well as to gain information about the person logged in, the resource owner, which is often called identity. When an Authorization Server supports OIDC, it is sometimes 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. For example, an application could support SSO with social networking services, such as Facebook or Twitter, so that users can choose to leverage a login they already have and are comfortable using. One way you might think of OIDC is kind of like using an ATM. The ATM machine is the client. Its job is to access data, such as your bank balance, and perform banking transactions, such as withdraw money from an account or deposit money into an account. Your bank card is the token that's issued by the bank. It not only gives the ATM access to your account, the Authorization, 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. Let's revisit our terrible pun of the day example. The OpenID Connect flow looks the same as OAuth. The only differences are, is in the initial request, 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 as before and issues an authorization code back to the client using the resource owner's browser. The key difference in OIDC is when the client exchanges the authorization code for an access token, the client receives both an access token and an ID token. As before, the access token is a value the client doesn't understand. The ID token, however, is very different. The ID token is a specifically formatted string of characters known as a JSON web token, or JWT. JWTs are sometimes pronounced jotts. 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, 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. With OIDC, there's also a standard way the client can request additional identity information from the authorization server, such as your email address using the access token. Well, that's it, folks. That is OAuth and OIDC in a nutshell. If you'd like to dig deeper, there's some additional resources linked in the description below. I hope you found this video helpful. Please like, subscribe, and leave me comments down below. I'd love to hear from you. Once you're done, get out there and be awesome.