An Illustrated Guide to OAuth and OpenID Connect

Summary

This video script simplifies the complexities of OAuth and OpenID Connect, two crucial standards for secure data sharing between applications. It explains OAuth 2.0 as a security protocol that allows apps to access user data without passwords, using a key-based authorization process. The script then introduces OpenID Connect as an extension of OAuth, adding user authentication and identity information to the data access capabilities. Through an engaging example of a pun-sharing website, it illustrates the OAuth flow, terminology, and the benefits of using these standards for both users and developers.

Takeaways

• 🔐 OAuth 2.0 is a security standard that allows one application to access data in another application without sharing your username and password.
• 📜 The OAuth flow includes steps for granting permission or consent, often referred to as authorization or delegated authorization.
• 👤 The key roles in OAuth are the resource owner (you), the client (the application requesting access), the authorization server (where you have an account), and the resource server (the service you want to use).
• 🔄 The authorization code flow is the most common OAuth 2.0 flow, involving a series of steps to securely exchange information between services.
• 🔑 The authorization server issues a temporary authorization code, which the client exchanges for an access token to access the resource server on your behalf.
• 🏷️ Scopes define the specific permissions the client is requesting, such as access to data or the ability to perform certain actions.
• 🔗 OpenID Connect (OIDC) is a layer on top of OAuth 2.0 that adds functionality for authentication and providing profile information about the logged-in person.
• 🎟️ With OIDC, the client receives both an access token and an ID token, with the latter containing claims about the user's identity.
• 🔄 The OIDC flow is similar to OAuth, but with the use of a specific scope and the issuance of an ID token, which includes identity information.
• 🌐 OIDC enables single sign-on (SSO) scenarios, allowing users to log in once and access multiple applications with the same credentials.

Q & A

What is the primary issue with sharing your username and password with other services?

Sharing your username and password with other services is problematic because there's no guarantee that the organization will keep your credentials safe or that their service won't access more of your personal information than necessary.

What is OAuth 2.0 and how does it improve upon the old method of sharing credentials?

OAuth 2.0 is a security standard that allows one application to access your data in another application without sharing your username and password. Instead, you give one app a key that grants specific permissions to access your data or perform actions on your behalf.

Can you explain the authorization code flow in OAuth 2.0?

The authorization code flow is a common OAuth 2.0 flow where the client redirects the user to the authorization server, which then asks for permission. If granted, the authorization server sends a temporary authorization code back to the client, which it exchanges for an access token to access the user's data.

What is the role of the 'resource owner' in OAuth 2.0?

The resource owner is the entity that owns the identity, data, and any actions that can be performed with their account. In the context of the script, the resource owner is the user who grants or denies access to their data to the client application.

What is the difference between an authorization server and a resource server?

The authorization server is the service that authenticates the resource owner and issues access tokens to the client. The resource server is the service that holds the protected resources and uses the access token to verify that the client is allowed to access the resource.

What is the purpose of a redirect URI in OAuth 2.0?

The redirect URI is the endpoint to which the authorization server redirects the resource owner back after they have granted or denied permission. This URI is provided by the client and is used to return the authorization code or access token.

How does OpenID Connect extend the functionality of OAuth 2.0?

OpenID Connect is a layer that sits on top of OAuth 2.0 and adds functionality for authentication and providing basic profile information about the person who is logged in. It allows clients to verify the identity of the resource owner and obtain information like their name and email address.

What is the significance of the ID token in OpenID Connect?

The ID token in OpenID Connect is a specially formatted string (JSON Web Token or JWT) that contains claims about the resource owner, such as their ID, name, and authentication information. It provides both authorization and identity information to the client.

What is the concept of Single Sign-On (SSO) and how does OpenID Connect support it?

Single Sign-On (SSO) is a concept where a user logs in once and gains access to multiple applications without needing to log in again. OpenID Connect supports SSO by allowing clients to establish a login session and gain information about the logged-in user across different applications.

How does the OAuth 2.0 flow differ from the OpenID Connect flow?

The OAuth 2.0 flow focuses on authorization and accessing data, while the OpenID Connect flow includes the same authorization steps but also provides an ID token with identity information. The key difference is that OIDC uses a specific scope in the initial request to indicate that it will return an ID token along with the access token.

Outlines

00:00

🔐 Introduction to OAuth and OpenID Connect

This paragraph introduces the concepts of OAuth and OpenID Connect, explaining the challenges of understanding their terminology and the conflicting information available. The video aims to simplify these standards using clear illustrations. It starts with the historical practice of sharing information by exchanging usernames and passwords, which is now considered insecure. OAuth 2.0 is introduced as a security standard that allows one application to access data from another without sharing credentials directly. The process of granting permission is called authorization, and the video uses the example of a website called 'Terrible Pun of the Day' to illustrate how OAuth works in practice, including the steps of choosing an email provider, logging in, and granting access to contacts.

05:01

🔑 OAuth Terminology and Flow

This paragraph delves into the specific terms and components of OAuth 2.0. It defines the roles of the resource owner (the user), the client (the application requesting access), the authorization server (the service where the user has an account), and the resource server (the service providing the data or actions). It explains the concept of the redirect URI, response type, scope, and the process of client identification using client ID and client secret. The paragraph also describes the authorization code flow, which involves the client requesting access, the authorization server verifying the user, the user granting permission, and the client receiving an access token to use with the resource server.

10:02

📜 OpenID Connect Overview

This paragraph introduces OpenID Connect (OIDC) as an extension of OAuth 2.0, focusing on user authentication and providing profile information. It explains that while OAuth is about authorization and granting access, OIDC adds a layer for identifying the user. The paragraph uses the analogy of an ATM to describe how OIDC works, with the ATM being the client, the bank card as the token, and the bank infrastructure as the underlying OAuth framework. The paragraph also discusses the process of OIDC, including the use of an ID token (JWT) that contains identity information about the user, and how the client can request additional identity information using the access token.

15:04

🏁 Wrapping Up OAuth and OIDC

The final paragraph summarizes the key points about OAuth and OIDC, emphasizing their roles in secure data access and user authentication. It mentions that OIDC provides not just a key (access token) but also a badge (ID token) that contains basic user information. The paragraph encourages viewers to explore additional resources for a deeper understanding and invites feedback through likes, subscriptions, and comments. It concludes with a call to action to apply the knowledge gained from the video.

Keywords

💡OAuth

OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites without giving them the passwords. In the video, OAuth 2.0 is described as a security standard that allows one application to access data from another application on behalf of the user, without requiring the user's password.

💡OpenID Connect

OpenID Connect (OIDC) is an authentication layer that sits on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. In the context of the video, OIDC is explained as a layer that adds functionality around login and profile information on top of OAuth 2.0, providing not just access but also identity information.

💡Resource Owner

The term 'Resource Owner' refers to the entity that can grant access to a resource. In the video, the resource owner is the user who owns the identity, data, and actions that can be performed with their account. The video uses the example of the user authorizing the 'terrible pun of the day' website to access their contacts.

💡Client

In OAuth, the 'Client' is the application that wants to access the resource owner's data. The video explains that the client is the application that requests access to the user's data on another application, such as the 'terrible pun of the day' website wanting to access the user's contacts.

💡Authorization Server

The 'Authorization Server' is the server that authenticates the resource owner and issues access tokens to the client after getting proper authorization. In the video, the authorization server is the service where the user logs in to grant permission to the client to access their data, such as the email service provider in the example.

💡Resource Server

The 'Resource Server' is the server hosting the protected resources, and it is responsible for accepting and responding to protected resource requests using access tokens. The video mentions that the resource server is the application, API, or service that the client wants to use on behalf of the resource owner.

💡Redirect URI

The 'Redirect URI' is the URI to which the authorization server redirects the resource owner when the authorization request is complete. In the video, the redirect URI is described as the URL to which the authorization server redirects the user after granting permission to the client.

💡Scope

In OAuth, 'Scope' refers to the specific areas of access or actions that the client is requesting from the resource owner. The video explains that scopes are the granular permissions the client wants, such as access to data or to perform actions.

💡Access Token

An 'Access Token' is a string representing an authorization credential used by the client to access the resource. The video describes the access token as a key that the client uses to communicate with the resource server on behalf of the user.

💡ID Token

The 'ID Token' is a security token that contains a set of claims to be used in an OpenID Connect authentication flow. The video explains that the ID token is a specially formatted string (JWT) that contains identity information about the user, such as their ID and name, and is provided to the client along with the access token during the OIDC flow.

💡Single Sign-On (SSO)

Single Sign-On (SSO) is a property of access control of multiple related, but independent software systems. With this property, a user logs in once and gains access to all systems without being required to log in again at each of them. The video touches on SSO as a scenario enabled by OpenID Connect, where a user can use one login across multiple applications, such as using a social networking service login for various websites.

Highlights

OAuth and OpenID Connect can be confusing due to their terminology and conflicting information.

In the past, sharing information between services required sharing usernames and passwords, which is insecure.

OAuth 2.0 is a security standard that allows one application to access data in another application without sharing passwords.

OAuth 2.0 uses a key for granting permissions, which can be revoked at any time.

The OAuth flow is a process of granting consent and exchanging information securely between services.

Key OAuth terminology includes resource owner, client, authorization server, and resource server.

The authorization code flow is the most common OAuth 2.0 flow and involves visible and invisible steps.

OpenID Connect is a layer on top of OAuth 2.0 that adds login and profile information functionality.

OpenID Connect enables single sign-on (SSO) across multiple applications.

An identity provider in OpenID Connect provides information about the resource owner back to the client.

The OpenID Connect flow is similar to OAuth, but it includes an ID token in addition to the access token.

The ID token is a JSON web token (JWT) that contains identity information about the user.

Claims within the ID token provide various pieces of information about the user's identity and authentication.

OpenID Connect allows clients to request additional identity information using the access token.

The video aims to simplify understanding of OAuth and OpenID Connect with illustrations and examples.

The example of 'terrible pun of the day' is used to demonstrate the OAuth and OpenID Connect flows.

The video concludes with additional resources for further learning on OAuth and OpenID Connect.

Transcripts

hey have you ever tried to learn about

OAuth and open ID 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

hikes you should never be required to

share your username and password your

credentials to another service there's

no guarantee than our organization will

keep your credential 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 oo-oo-oo auth 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

terrible pun of the day 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 everyone needs

bad puns a good thing 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 if not you get a prompt to log

in after 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 terrible pun of the day

access to your contacts assuming you

haven't changed your mind you click

allow you are redirected back to the

terrible pun of the day and the

application can now read your contacts

and that's the only thing it can do

terrible pun of the day can now send

emails to everyone you know and you'll

be the most popular person forever

ooofff 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

state

we're the two services agree on a secure

way of exchanging information the

previous terrible pun of the day example

uses the most common 2.0 flow known as

the authorization code flow now before

we dive into more details on what oh ah

this' 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

terrible pun of the day 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 a 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 and 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

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 owners 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

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

for granting access to data and features

from one application to another o auth

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 open ID Connect sometimes

referred to as oh I DC 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 o IDC 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 worth

enables authorization from one app to

another o IDC 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 oh I DC it is sometimes called

an identity provider since it provides

information about the resource owner

back to the client open ID 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 oh I D C is kind of

like using an ATM the ATM machine is the

client it's 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 oh I DC sits on

top of OAuth and cannot work without the

underlying oo auth framework let's

revisit our terrible pun of the day

example the open ID connect flow looks

the same as ooofff

the only differences are is in the

initial request a specific scope of open

ID is used this lets the authorization

server know this will be an open ID

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 owners browser the key

difference in OID C 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 JWT s are sometimes pronounced shots

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 tokens

expiration and it can tell if anyone has

tried to tamper with the JWT the data

inside the ID token are called claims

with oh I D C 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 oo-oo-oo ID c in

a nutshell if you'd like to dig deeper

there are 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 until

next time get out there and be awesome