Lecture

Contributors: Conner Swenberg

OAuth 2.0

You have most likely interacted with OAuth already via "Login with Facebook" or "Login with Google". Either of these options allows you to authenticate yourself without having to use a separate username and password for a particular service, just piggy-back off of another service's authentication.

Stakeholder

Benefit

Service / application

Streamlines user registration / login

Users "resource owners"

Minimizes number of accounts

API "resource server" (Facebook/Google)

Gains valuable data on your use of other services

Registration

Our service that intends to use OAuth needs to register itself with the resource server, receiving their own client ID and client secret.

Redirect URI

Our service also needs to declare to the resource server a redirect URI. This tells the resource server where to bring users back to after logging with their authentication system.

Code Generation

  1. Service pulls up a custom resource server login page unique to their client ID and redirect URI.

  2. Client returned a new code upon successful login

  3. Client will use this code to fetch a session token from the resource server

BELOW IS UNDER DEVELOPMENT

OAuth 1.0

creds

Roles

Credentials

Flow

Signature

OAuth 2.0

creds

Roles

Flow

Grant Types

Authorization Code

Implicit

Resource Owner Password

Client Credential

Client Authentication Models

Scope and Access Control

OpenID Connect

Claims

Last updated