Day 1

Day 1

(1) Intro (~ 10 minutes)

• About Me
• Objectives

Day 1

(1) Intro (~ 10 minutes)

• About Me
• Objectives

(2) Theory (~ 2 hours)

• Authentication vs Authorization
• OAuth
  • What is OAuth?
  • Terminology
  • Authorization Code flow
  • Grant types
  • History of OAuth

Day 1

(1) Intro (~ 10 minutes)

• About Me
• Objectives

(2) Theory (~ 2 hours)

• Authentication vs Authorization
• OAuth
  • What is OAuth?
  • Terminology
  • Authorization Code flow
  • Grant types
  • History of OAuth

(3) Practice (~ 5 hours)

• Developing an OAuth 2.0 Authorization Server with Node

Day 2

Day 2

(1) Theory (~ 1 hour)

• Day 1 Review
• OpenID Connect
  • What is OpenID Connect?
  • How does OpenID Connect work with OAuth 2.0?
  • JSON Web Tokens (JWT)

Day 2

(1) Theory (~ 1 hour)

• Day 1 Review
• OpenID Connect
  • What is OpenID Connect?
  • How does OpenID Connect work with OAuth 2.0?
  • JSON Web Tokens (JWT)

(2) Practice (~ 5 hours)

• Adding OpenID Connect to the OAuth 2.0 Server
• Developing a Client application with Node and Express

Day 2

(1) Theory (~ 1 hour)

• Day 1 Review
• OpenID Connect
  • What is OpenID Connect?
  • How does OpenID Connect work with OAuth 2.0?
  • JSON Web Tokens (JWT)

(2) Practice (~ 5 hours)

• Adding OpenID Connect to the OAuth 2.0 Server
• Developing a Client application with Node and Express

(3) Theory (~ 1 hour)

• Final Review
• Next Steps

About Michael

$ whoami
michael.herman

About Michael

$ whoami
michael.herman

Senior Software Engineer from Denver, CO

1. Full-stack + DevOps Contractor
2. TestDriven.io

About Michael

$ whoami
michael.herman

Senior Software Engineer from Denver, CO

1. Full-stack + DevOps Contractor
2. TestDriven.io

Also

1. Founder and Organizer of Denver Node.js Meetup Group
2. Former Lead Instructor at Galvanize
3. Co-founder/author of Real Python
4. 😍 - tech writing/education, open source, financial models, radiohead

Objectives

Objectives

By the end of this training, you will be able to:

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

2. Explain what OAuth 2.0 is and how it differs from OAuth 1.0

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

2. Explain what OAuth 2.0 is and how it differs from OAuth 1.0

3. Describe the various OAuth 2.0 grant types and when it's appropriate to use each

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

2. Explain what OAuth 2.0 is and how it differs from OAuth 1.0

3. Describe the various OAuth 2.0 grant types and when it's appropriate to use each

4. Implement an OAuth 2.0 server with Node

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

2. Explain what OAuth 2.0 is and how it differs from OAuth 1.0

3. Describe the various OAuth 2.0 grant types and when it's appropriate to use each

4. Implement an OAuth 2.0 server with Node

5. Explain what OpenID Connect is and how it works with OAuth 2.0

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

2. Explain what OAuth 2.0 is and how it differs from OAuth 1.0

3. Describe the various OAuth 2.0 grant types and when it's appropriate to use each

4. Implement an OAuth 2.0 server with Node

5. Explain what OpenID Connect is and how it works with OAuth 2.0

6. Implement OpenID Connect with Node

Objectives

By the end of this training, you will be able to:

1. Describe the difference between authentication and authorization

2. Explain what OAuth 2.0 is and how it differs from OAuth 1.0

3. Describe the various OAuth 2.0 grant types and when it's appropriate to use each

4. Implement an OAuth 2.0 server with Node

5. Explain what OpenID Connect is and how it works with OAuth 2.0

6. Implement OpenID Connect with Node

7. Develop a Client app to interact with an OAuth 2.0 and OpenID Connect server

Authentication vs Authorization

Authentication vs Authorization

"Who are you and what are you allowed to do?"

Authentication vs Authorization

"Who are you and what are you allowed to do?"

Authentication

• Verifying that someone is who they claim to be.
• Who are you?

Authentication vs Authorization

"Who are you and what are you allowed to do?"

Authentication

• Verifying that someone is who they claim to be.
• Who are you?

Authorization

• Verifying which resources a user can access and what they are allowed to do with those resources.
• What are you allowed to do?

Authentication vs Authorization

"Who are you and what are you allowed to do?"

Authentication

• Verifying that someone is who they claim to be.
• Who are you?

Authorization

• Verifying which resources a user can access and what they are allowed to do with those resources.
• What are you allowed to do?

Single Sign-On (SSO)

• Allows a user to enter one set of credentials in order to access multiple applications.

What is OAuth?

What is OAuth?

Oauth is an open standard for authorization.

"An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications."

What is OAuth?

Oauth is an open standard for authorization.

"An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications."

It's all about delegation:

What is OAuth?

Oauth is an open standard for authorization.

"An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications."

It's all about delegation:

1. The Client application accesses resources, from a Resource Server, on behalf of the User.
2. The User does not have to share their credentials with the Client.

What is OAuth?

Oauth is an open standard for authorization.

"An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications."

It's all about delegation:

1. The Client application accesses resources, from a Resource Server, on behalf of the User.
2. The User does not have to share their credentials with the Client.

Compared to OAuth 1.0, OAuth 2.0:

• Is slightly simpler to implement
• Adds time to live (TTL) to the Access Tokens
• Supports mobile and desktop apps
• No longer requires Client applications to have cryptography

Terminology

Terminology

Grant Types

Grant Types

Grant Types

Questions

Grant Types

Questions

• Which grant should you use? Decision tree

Grant Types

Questions

• Which grant should you use? Decision tree

• First vs third party client?

  • First party clients are clients that you trust. For example, Twitter probably trusts the Twitter iPhone app since they own it.
  • Third party clients are clients that you don't trust.

Grant Types

Questions

• Which grant should you use? Decision tree

• First vs third party client?

  • First party clients are clients that you trust. For example, Twitter probably trusts the Twitter iPhone app since they own it.
  • Third party clients are clients that you don't trust.

• Access Token Owner? Do you not need the user's permission to access the restricted resources?

Grant Types

Questions

• Which grant should you use? Decision tree

• First vs third party client?

  • First party clients are clients that you trust. For example, Twitter probably trusts the Twitter iPhone app since they own it.
  • Third party clients are clients that you don't trust.

• Access Token Owner? Do you not need the user's permission to access the restricted resources?

Source: A Guide to OAuth 2.0 Grants

Authorization Code Flow

Authorization Code Flow

[Step 1] Client redirects the Resource Owner to the Authorization Server

Authorization Code Flow

[Step 1] Client redirects the Resource Owner to the Authorization Server

[Step 2] Resource Owner grants authorization

[Step 3] Authorization Server redirects the Resource Owner back to the Client with an Authorization Code

Authorization Code Flow (continued...)

Authorization Code Flow (continued...)

[Step 4] Client exchanges Authorization Code for Access Token

Authorization Code Flow (continued...)

[Step 4] Client exchanges Authorization Code for Access Token

[Step 5] Authorization Server grants Access Token

Authorization Code Flow (continued...)

Authorization Code Flow (continued...)

[Step 6] Client uses the Access Token to access protected resources, from the Resource Server, on behalf of the Resource Owner

Authorization Code Flow (continued...)

[Step 6] Client uses the Access Token to access protected resources, from the Resource Server, on behalf of the Resource Owner

What's different about this flow for the other grant types—Implicit, Resource Owner Credentials, Client Credentials? Understanding OAuth2

History of OAuth

History of OAuth

Before OAuth

History of OAuth

Before OAuth

The User would provide their credentials directly to the Client app.

History of OAuth

Before OAuth

The User would provide their credentials directly to the Client app.

Problems

1. Client stores User's password (one more application with your password)
2. Client gets complete access to the User's account (scope)
3. User cannot revoke access to the Client unless they reset their password

History of OAuth

Before OAuth

The User would provide their credentials directly to the Client app.

Problems

1. Client stores User's password (one more application with your password)
2. Client gets complete access to the User's account (scope)
3. User cannot revoke access to the Client unless they reset their password

Oauth 1.0

History of OAuth

Before OAuth

The User would provide their credentials directly to the Client app.

Problems

1. Client stores User's password (one more application with your password)
2. Client gets complete access to the User's account (scope)
3. User cannot revoke access to the Client unless they reset their password

Oauth 1.0

Introduced in December 2007 to prevent the Client application from having to directly handle the User's credentials.

History of OAuth

Before OAuth

The User would provide their credentials directly to the Client app.

Problems

1. Client stores User's password (one more application with your password)
2. Client gets complete access to the User's account (scope)
3. User cannot revoke access to the Client unless they reset their password

Oauth 1.0

Introduced in December 2007 to prevent the Client application from having to directly handle the User's credentials.

Problems

1. Difficult to implement
2. Complex cryptographic requirements
3. Poor support for native desktop and mobile apps

History of OAuth (continued...)

History of OAuth (continued...)

OAuth 2.0

First came out in April 2010.

History of OAuth (continued...)

OAuth 2.0

First came out in April 2010.

Problems

1. Still difficult to implement
2. Difficult for the User to update the scope
3. Security concerns

History of OAuth (continued...)

OAuth 2.0

First came out in April 2010.

Problems

1. Still difficult to implement
2. Difficult for the User to update the scope
3. Security concerns

Recommended reads

• OAuth 2.0 and the Road to Hell
• OAuth 2 Simplified
• Introducing TAuth: Why OAuth 2.0 is bad for banking APIs and how we're fixing it

Check for Understanding

Check for Understanding

• What's the difference between authentication and authorization?

Check for Understanding

• What's the difference between authentication and authorization?

• What is OAuth?

Check for Understanding

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

Check for Understanding

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

• How does the grant type affect the OAuth 2.0 authorization flow?

🤔

What are we building?

What are we building?

Day 1

• We'll build an OAuth 2.0 Authorization Server with Node, Express, and Postgres that uses the Authorization Code grant type.

What are we building?

Day 1

• We'll build an OAuth 2.0 Authorization Server with Node, Express, and Postgres that uses the Authorization Code grant type.

Day 2

• We'll add OpenID Connect to the existing server.
• Then, we'll create a separate Client application that can authorize against the Authorization Server.

What are we building?

Day 1

• We'll build an OAuth 2.0 Authorization Server with Node, Express, and Postgres that uses the Authorization Code grant type.

Day 2

• We'll add OpenID Connect to the existing server.
• Then, we'll create a separate Client application that can authorize against the Authorization Server.

Prerequisites

You should:

1. Have Node (v11.12.0), NPM (v6.7.0), Postgres (v9.6+), and git installed.
2. Be familiar with Javascript syntax and fundamentals.
3. Have a basic understanding of the Unix command line.
4. Be able to build a RESTful API with Node, Express, and Postgres.

Getting Started

Getting Started

Clone down the node-oauth-openid repo and check out the base tag:

$ git clone https://github.com/mjhea0/node-oauth-openid
$ git checkout -b base

Getting Started

Clone down the node-oauth-openid repo and check out the base tag:

$ git clone https://github.com/mjhea0/node-oauth-openid
$ git checkout -b base

Install the dependencies:

$ npm install

Getting Started

Clone down the node-oauth-openid repo and check out the base tag:

$ git clone https://github.com/mjhea0/node-oauth-openid
$ git checkout -b base

Install the dependencies:

$ npm install

Run the server:

$ npm start

Ensure the server is up and running at http://localhost:3001/ and http://localhost:3001/ping.

Getting Started

Clone down the node-oauth-openid repo and check out the base tag:

$ git clone https://github.com/mjhea0/node-oauth-openid
$ git checkout -b base

Install the dependencies:

$ npm install

Run the server:

$ npm start

Ensure the server is up and running at http://localhost:3001/ and http://localhost:3001/ping.

Let's review app.js together...

Structure

Structure

Authorize Endpoints

Structure

Authorize Endpoints

/oauth/authorize - GET

1. Query params - Grant type, client ID, redirect URI, state
2. Force the user to log in
3. Ensure the client exists
4. Redirect user to the dialog endpoint

Structure

Authorize Endpoints

/oauth/authorize - GET

1. Query params - Grant type, client ID, redirect URI, state
2. Force the user to log in
3. Ensure the client exists
4. Redirect user to the dialog endpoint

/oauth/authorize/dialog - GET

1. Display authorize dialog

Structure

Authorize Endpoints

/oauth/authorize - GET

1. Query params - Grant type, client ID, redirect URI, state
2. Force the user to log in
3. Ensure the client exists
4. Redirect user to the dialog endpoint

/oauth/authorize/dialog - GET

1. Display authorize dialog

/oauth/authorize/dialog - POST

1. If authorized, generate Authorization Code and redirect user to the redirect URI with the Authorization Code and state
2. If not authorized, send back an error

Structure (continued...)

Structure (continued...)

Token Endpoint

Structure (continued...)

Token Endpoint

/oauth/token - POST

1. Payload - Authorization Code
2. Ensure the Authorization Code has not expired or been consumed
3. Mark Authorization Code as consumed
4. Generate an Access Token (and an optional Refresh Token)
5. Respond via JSON with the Access Token, optional Refresh Token, and how long the Access Token is good for

User Info Endpoint

Structure (continued...)

Token Endpoint

/oauth/token - POST

1. Payload - Authorization Code
2. Ensure the Authorization Code has not expired or been consumed
3. Mark Authorization Code as consumed
4. Generate an Access Token (and an optional Refresh Token)
5. Respond via JSON with the Access Token, optional Refresh Token, and how long the Access Token is good for

User Info Endpoint

/oauth/userinfo - GET

1. Header - Access Token (Authorization: Bearer <token>)
2. Ensure the Authorization Code is valid
3. If valid, send back true
4. If not valid, send back false

Structure (continued...)

Structure (continued...)

Models

Structure (continued...)

Models

1. user - user ID, email, client ID
2. client - client ID, name, redirect URI
3. authCode - code, created at, consumed, user ID
4. accessToken - token, created at, expires in, token type (e.g., bearer), user ID, refresh token (optional)

Structure (continued...)

Models

1. user - user ID, email, client ID
2. client - client ID, name, redirect URI
3. authCode - code, created at, consumed, user ID
4. accessToken - token, created at, expires in, token type (e.g., bearer), user ID, refresh token (optional)

Bearer Token

Structure (continued...)

Models

1. user - user ID, email, client ID
2. client - client ID, name, redirect URI
3. authCode - code, created at, consumed, user ID
4. accessToken - token, created at, expires in, token type (e.g., bearer), user ID, refresh token (optional)

Bearer Token

Bearer Tokens are probably the most popular type of Access Token. They must be unique, nonsequential, and nonguessable.

Structure (continued...)

Models

1. user - user ID, email, client ID
2. client - client ID, name, redirect URI
3. authCode - code, created at, consumed, user ID
4. accessToken - token, created at, expires in, token type (e.g., bearer), user ID, refresh token (optional)

Bearer Token

Bearer Tokens are probably the most popular type of Access Token. They must be unique, nonsequential, and nonguessable.

Using Bearer Tokens:

1. Authorization Request Header Field: Authorization: Bearer 4ae6ce68-4c59-4313-94e2-fcc2932cf5ca
2. Form-Encoded Body Parameter: Content-Type: application/x-www-form-urlencoded, access_token=mF_9.B5f-4.1JqM
3. URI Query Parameter: resource?access_token=mF_9.B5f-4.1JqM

Implementation

Implementation

So, we need to implement the following:

1. Models: user, client, authCode, accessToken
2. Routes: /oauth/authorize (GET), /oauth/authorize/dialog (GET and POST), /oauth/token (POST), /oauth/userinfo (GET)

Implementation

So, we need to implement the following:

1. Models: user, client, authCode, accessToken
2. Routes: /oauth/authorize (GET), /oauth/authorize/dialog (GET and POST), /oauth/token (POST), /oauth/userinfo (GET)

Let's skip user log in for now and get something working. What else can we punt in order to get a working prototype up and running?

Implementation

So, we need to implement the following:

1. Models: user, client, authCode, accessToken
2. Routes: /oauth/authorize (GET), /oauth/authorize/dialog (GET and POST), /oauth/token (POST), /oauth/userinfo (GET)

Let's skip user log in for now and get something working. What else can we punt in order to get a working prototype up and running?

Where do we begin?

Homework

1. Finish the Node Authentication Server
2. Read User Authentication with OAuth 2.0 and Understanding OAuth 2.0 and OpenID Connect

Day 1 Review

Day 1 Review

• What's the difference between authentication and authorization?

Day 1 Review

• What's the difference between authentication and authorization?

• What is OAuth?

Day 1 Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

Day 1 Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

• How does the grant type affect the OAuth 2.0 authorization flow?

🤔

What is OpenID Connect?

What is OpenID Connect?

OpenID Connect (or OIDC), the latest version of OpenID, is a standard for authentication, issued by the OpenID Foundation in February 2014.

What is OpenID Connect?

OpenID Connect (or OIDC), the latest version of OpenID, is a standard for authentication, issued by the OpenID Foundation in February 2014.

How does OpenID Connect work with OAuth 2.0?

What is OpenID Connect?

OpenID Connect (or OIDC), the latest version of OpenID, is a standard for authentication, issued by the OpenID Foundation in February 2014.

How does OpenID Connect work with OAuth 2.0?

• OpenID Connect extends OAuth 2.0, adding an extra layer for handling user authentication. It's a superset of OAuth 2.0.

What is OpenID Connect?

OpenID Connect (or OIDC), the latest version of OpenID, is a standard for authentication, issued by the OpenID Foundation in February 2014.

How does OpenID Connect work with OAuth 2.0?

• OpenID Connect extends OAuth 2.0, adding an extra layer for handling user authentication. It's a superset of OAuth 2.0.

• With OpenID Connect, the token endpoint returns an ID Token instead of an Access Token.

What is OpenID Connect?

OpenID Connect (or OIDC), the latest version of OpenID, is a standard for authentication, issued by the OpenID Foundation in February 2014.

How does OpenID Connect work with OAuth 2.0?

• OpenID Connect extends OAuth 2.0, adding an extra layer for handling user authentication. It's a superset of OAuth 2.0.

• With OpenID Connect, the token endpoint returns an ID Token instead of an Access Token.

• The ID Token is a JSON Web Token that contains information about the authenticated user.

JSON Web Tokens (JWT)

JSON Web Tokens (JWT)

A JSON Web Token (or JWT) is a JSON-based standard for securely transmitting information. They can signed (JWS) or encrypted (JWE).

JSON Web Tokens (JWT)

A JSON Web Token (or JWT) is a JSON-based standard for securely transmitting information. They can signed (JWS) or encrypted (JWE).

Benefits

• Stateless: Since tokens contain the required info to verify a user's identity, scaling is easier as you do not have to maintain a session store.
• Single Sign On: After a token is generated, you can have your users access a variety of resources without having to re-authenticate them.

JSON Web Tokens (JWT)

A JSON Web Token (or JWT) is a JSON-based standard for securely transmitting information. They can signed (JWS) or encrypted (JWE).

Benefits

• Stateless: Since tokens contain the required info to verify a user's identity, scaling is easier as you do not have to maintain a session store.
• Single Sign On: After a token is generated, you can have your users access a variety of resources without having to re-authenticate them.

Drawbacks

• Cross-site Scripting (XSS) attacks: Storing tokens in either local or session storage can lead to XSS attacks. Because of this, it's a good idea to store them in a cookie with httpOnly and secure flags.

JSON Web Tokens (JWT)

A JSON Web Token (or JWT) is a JSON-based standard for securely transmitting information. They can signed (JWS) or encrypted (JWE).

Benefits

• Stateless: Since tokens contain the required info to verify a user's identity, scaling is easier as you do not have to maintain a session store.
• Single Sign On: After a token is generated, you can have your users access a variety of resources without having to re-authenticate them.

Drawbacks

• Cross-site Scripting (XSS) attacks: Storing tokens in either local or session storage can lead to XSS attacks. Because of this, it's a good idea to store them in a cookie with httpOnly and secure flags.

Recommended reads

• JSON Web Token (JWT)
• Introduction to JSON Web Tokens
• What is the difference between encrypting and signing?

Adding OpenID

Steps

• Add scope to the /authorize endpoint

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Questions

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Questions

• What are JWT Claims?

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Questions

• What are JWT Claims?

• Which claims are required? Which claims should we use?

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Questions

• What are JWT Claims?

• Which claims are required? Which claims should we use?

Security Recommendations

• Always use HTTPS!

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Questions

• What are JWT Claims?

• Which claims are required? Which claims should we use?

Security Recommendations

• Always use HTTPS!

• Issue short lived bearer tokens

Adding OpenID

Steps

• Add scope to the /authorize endpoint

• Create (via jsonwebtoken) then return an ID Token in the /token endpoint

• Modify the /userinfo to decode the ID Token and return user info

Questions

• What are JWT Claims?

• Which claims are required? Which claims should we use?

Security Recommendations

• Always use HTTPS!

• Issue short lived bearer tokens

• Don't pass bearer token in page URLs

Client Application

Client Application

Let's spin up a new Express application to serve as the Client.

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

• On button click, redirect User (with Grant type, client ID, redirect URI, Scope, and State) to the Authorization Server's /oauth/authorize endpoint

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

• On button click, redirect User (with Grant type, client ID, redirect URI, Scope, and State) to the Authorization Server's /oauth/authorize endpoint

• If the User authorization is successful, the User is redirect back to the Client, to the redirect URI, with the Authorization Code and State

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

• On button click, redirect User (with Grant type, client ID, redirect URI, Scope, and State) to the Authorization Server's /oauth/authorize endpoint

• If the User authorization is successful, the User is redirect back to the Client, to the redirect URI, with the Authorization Code and State

• With the Authorization Code in hand, request Access Token

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

• On button click, redirect User (with Grant type, client ID, redirect URI, Scope, and State) to the Authorization Server's /oauth/authorize endpoint

• If the User authorization is successful, the User is redirect back to the Client, to the redirect URI, with the Authorization Code and State

• With the Authorization Code in hand, request Access Token

• If the Authorization Code is valid, an ID Token is sent back

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

• On button click, redirect User (with Grant type, client ID, redirect URI, Scope, and State) to the Authorization Server's /oauth/authorize endpoint

• If the User authorization is successful, the User is redirect back to the Client, to the redirect URI, with the Authorization Code and State

• With the Authorization Code in hand, request Access Token

• If the Authorization Code is valid, an ID Token is sent back

• Store the ID token

Client Application

Let's spin up a new Express application to serve as the Client.

Functionality

• Display "Authorize" button on page load to /

• On button click, redirect User (with Grant type, client ID, redirect URI, Scope, and State) to the Authorization Server's /oauth/authorize endpoint

• If the User authorization is successful, the User is redirect back to the Client, to the redirect URI, with the Authorization Code and State

• With the Authorization Code in hand, request Access Token

• If the Authorization Code is valid, an ID Token is sent back

• Store the ID token

• On requests to restricted resources, send the ID Token in the request header

Final Review

Final Review

• What's the difference between authentication and authorization?

Final Review

• What's the difference between authentication and authorization?

• What is OAuth?

Final Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

Final Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

• How does the grant type affect the OAuth 2.0 authorization flow?

Final Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

• How does the grant type affect the OAuth 2.0 authorization flow?

• What is OpenID Connect?

Final Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

• How does the grant type affect the OAuth 2.0 authorization flow?

• What is OpenID Connect?

• How does OpenID connect work with OAuth 2.0?

Final Review

• What's the difference between authentication and authorization?

• What is OAuth?

• Describe the various OAuth 2.0 grant types

• How does the grant type affect the OAuth 2.0 authorization flow?

• What is OpenID Connect?

• How does OpenID connect work with OAuth 2.0?

🤔

Next Steps

Next Steps

Finish the OpenID Connect + OAuth 2.0 server

1. Add Refresh Tokens (since Access Tokens are short-lived)
2. Incorporate Postgres
3. Address any other TODOs
4. Review the final code at node-oauth-openid

Anything else?

Next Steps

Finish the OpenID Connect + OAuth 2.0 server

1. Add Refresh Tokens (since Access Tokens are short-lived)
2. Incorporate Postgres
3. Address any other TODOs
4. Review the final code at node-oauth-openid

Anything else?

Additional Resources

1. Authentication and Authorization: OpenID vs OAuth2 vs SAML
2. SAML2 vs JWT: Understanding OpenID Connect Part 1
3. Libraries: oauth2orize, oauth2-server

Next Steps

Finish the OpenID Connect + OAuth 2.0 server

1. Add Refresh Tokens (since Access Tokens are short-lived)
2. Incorporate Postgres
3. Address any other TODOs
4. Review the final code at node-oauth-openid

Anything else?

Additional Resources

1. Authentication and Authorization: OpenID vs OAuth2 vs SAML
2. SAML2 vs JWT: Understanding OpenID Connect Part 1
3. Libraries: oauth2orize, oauth2-server

Contact Info

1. michael@mherman.org
2. mherman.org
3. @mikeherman

Next Steps

Finish the OpenID Connect + OAuth 2.0 server

1. Add Refresh Tokens (since Access Tokens are short-lived)
2. Incorporate Postgres
3. Address any other TODOs
4. Review the final code at node-oauth-openid

Anything else?

Additional Resources

1. Authentication and Authorization: OpenID vs OAuth2 vs SAML
2. SAML2 vs JWT: Understanding OpenID Connect Part 1
3. Libraries: oauth2orize, oauth2-server

Contact Info

1. michael@mherman.org
2. mherman.org
3. @mikeherman

Final Questions? ✌️