An Illustrated Guide to OAuth and OpenID Connect

Hey, have you ever tried to learn about OAuth and Open ID Connect but felt overwhelmed by all the strange terminology and jargon? There is also a lot of conflicting information which can be really frustrating. The goal of this video is to explain how these standards work. simplified and easy to understand illustrations and I hope we have a lot of fun, let's start in the days of the stone age of the Internet. Sharing information between services was easy, you simply gave your username and password from one service to another so they could log into your account and get whatever information they want hikes, you should never be asked to share your username and password , your credentials with another service, there is no guarantee that our organization will keep your credential secure or guarantee that its service will not access more personal information than necessary.

It may seem crazy, but some apps still try to get their way. Today, we have agreed upon standards to allow one service to securely access another's data. The first standard we need to cover is oo-oo-oo auth 2.0 is a security standard. where you give an app permission to access your data in another app instead of giving it your username and password, you can basically give an app a key that gives it specific permission to access your data or do things on your behalf In another app, the steps to grant permission or consent are often called authorization or even delegated authorization, you authorize an app to access your data or use features in another app on your behalf without giving them your password, plus you can recover that key whenever you want.

For example, let's say you've discovered a website called "terrible pun of the day" and you create an account to have it send a horrible pun as a text message every day to your phone. You love it so much that you want to share this site with everyone you know. Have you ever met someone online who wouldn't want to read a bad pun every day? I'm right? However, writing an email to every person on your contact list sounds like a lot of work and if you're like me, you'll be great. Try my best to avoid anything that smells like work, so here it is.

Everyone needs bad puns. Something good. The terrible pun of the day 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; Otherwise, you will receive a prompt to login after logging in or if you already have an active login session, you will be presented with a question similar to Do you want to give access to the terrible pun of the day to your contacts, assuming you haven't changed your mind, you click allow, you're redirected back to the terrible pun of the day and the app can now read your contacts and that's the only thing it can do. make the terrible pun of the day now you can email everyone you know and you will be the most popular person forever ooofff for winning, you just went through what is commonly known as the OAuth flow;

The OAuth flow in this example is made up of visible steps to grant consent, as well as an invisible state, the two services agreeing on a secure way to exchange information. The previous terrible pun of the day uses the most common 2.0 flow known as the authorization code flow now before I go into more detail about what oh ah this is doing, let's map some of the resource owner

oauth

terminologies, that it's you, you are the owner of your identity, your data and any actions that can be taken with your accounts, the client is the application in our example, terrible. pun of the day you want to access data or perform actions on its behalf 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 interface application programming 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 could be a third-party service the resource server trusts the redirect URI this is the URL to which the authorization server will redirect the owner of the resource after granting permission to the client this is sometimes called a callback URL response type the type of information the client expects to receive the most common type of response is code in the that the client expects to receive an authorization code.

These are the granular permissions that the customer wants, such as accessing data or performing actions. Consent. The authorization server takes the scopes that the client requests and checks against the resource. owner, whether or not he wants to grant permission to the client. Client ID. This ID is used to identify the client with the authorization server. There is also a client secret. This is a secret password that only the client and the authorization server know. This allows them to share securely. information privately behind the scenes authorization code this is a short-lived temporary code that the authorization server sends back to the client the client then privately sends the authorization code to the authorization server along with the client's secret to changing an access token an access token is the key that the client will now use to communicate with the resource server.

It's like a key or access 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 useful, let's review our example with a closer look to what happens throughout the OAuth flow. You, the owner of the resource, want to allow a terrible pun of the day the client to access his contacts so he can send invitations to all his friends. the client redirects your browser to the authorization server and includes with the request the client ID, the redirect URI, the response type, and one or more scopes that it needs.

The authorization server verifies who you are and, if necessary, requests a login. 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, the authorization server redirects to the client using the redirect URI along with a temporary authorization code, the client then it communicates directly with the authorization server, does not use the resource owners browser and securely sends its client ID, client secret and authorization code, the authorization server verifies the data and responds with a access token, access token is a value that the client does not understand as far as the client is concerned, access token is just a string of gibberish, however the client can use the access token to send requests to the server of resources.

The client is like here there is an access token. I would like the contacts associated with the resource owner of this token, the resource server checks the access token and if valid responds with the requested contacts, it is also important to note that long before you gave terrible permission to access to its contacts, the client and the authorization server established a working relationship, the authorization server generated a client ID and a client secret, sometimes called an application. ID and secret of the application and gave them to the client to use in all future 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 open ID Connect ooofff 2.0 is designed only for authorization to grant access to data and functions from one application to another or authentication is like giving an application a key to the client, that key is useful but it doesn't tell the client who you are or anything about you open ID Connect, sometimes called oh I DC is a thin layer that sits on top of OAuth 2.0 and adds functionality around the login and profile information of the person who is logged in Instead of a key or IDC it is like giving a badge to the client application.

The badge not only gives the customer specific permissions, but also provides basic information about who they are. Allows authorization from one application to another. o IDC allows a client to establish a login session often called authentication. as well as to obtain information about the person logged in to the owner of the resource, which is often called an identity when an authorization server supports oh I DC, it is sometimes called an identity provider as it provides information about the owner of the resource. appeal to the client. Open ID Connect allows for 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 media services such as Facebook or Twitter so that users can opt-in for leveraging a login they already have and are comfortable with.

One way you might think, oh I D C, it's like using an ATM, the ATM is the customer, its job is to access data like your bank balance and perform banking transactions, like withdrawing money from an account or depositing money into an account. your account. The bank card is the token issued by the bank, not only does it give the ATM access to your account and authorization, but it also has basic information about who you are, your identity, such as your name, and authentication information, such as when card expires, who issued the card, and the bank's phone number, an ATM cannot function without the underlying banking infrastructure.

Similarly, oh I DC sits on top of OAuth and can't work without the underlying oo authentication framework. Let's review our terrible pun of the day, open id

connect

ion flow example. Same as ooofff, the only difference is that a specific open ID scope is used in the initial request, this lets the authorization server know that it will be an open ID exchange. The authorization server follows the same steps as before and issues an authorization. return the code to the client using the resource owners browser, the key difference in OID C is that when the client exchanges the authorization code for an access token, the client receives both an access token and an ID token, since that before the access token is a value that the client does not understand the id token, however, it is very different.

The identification token is a specifically formatted string of characters known as a JSON or JWT web token. JWTs are sometimes steep shots. A JWT may seem 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 expiration of ID tokens, and can indicate if someone has attempted to manipulate the JWT. The data inside the ID token is called claims with oh I D C. There is also a standard way in which the client can request additional identity information from the authorization server, such as its email address using the access token, well, That's it folks, that's oo-oo-oo ID c in a nutshell, if you want to dig deeper there are some additional resources linked in the description. below I hope you found this video useful.

Please subscribe and leave me comments below. I would love to hear from you until next time, go out and be awesome.