# Lecture

## 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](https://docs.authlib.org/en/latest/basic/oauth1.html)

### Roles

### Credentials

### Flow

### Signature

## OAuth 2.0

[creds](https://docs.authlib.org/en/latest/basic/oauth2.html)

### Roles

### Flow

### Grant Types

#### Authorization Code

#### Implicit

#### Resource Owner Password

#### Client Credential

### Client Authentication Models

### Scope and Access Control

## OpenID Connect

### Claims