# OAuth2.0

---

## Authentication VS Authorization

### Authentication
中文為驗證，主要做身份驗證確保使用者不是怪人，常在後端API設計中看見，下面舉個簡單直白例子

>例子
有一家發大財公司在一棟商辦大樓，而商辦大樓多人雜亂，所以公司在大門設置門禁卡，只有公司內部的人才有這張卡來進入公司，而卡片代表持卡人的身份驗證物品

### Authorization
中文為授權，主要賦予使用者權限，與前者不同在於服務認得這人但能控制他的權限，在API設計授權可看到使用者可用哪幾隻API，簡單舉例

>例子
發大財公司有小明與小花員工，小明為一般的後端工程師，小花為老闆的漂亮秘書，而小明的門禁卡無法進入老闆的辦公室，但小花身為老闆秘書可以進入老闆辦公室，小花倍授權可進入

## Credentials
有了前面授權與權限的知識後，來講講Credentials(憑證)，Credentials只用來證明如：

- 使用者

- 應用程式

- 設備

這三者的身份資料信息，Credentials會提供給Auth Service來做身分證明，作用於授權與權限身份驗證，常見的Credentials類型有：

- 帳號與密碼

- Token

- 指紋、臉部紋路

- OTP(SMS or Email verify code)

- API Key

- RFID卡

# OAuth2.0(Open Authorization)
OAuth2.0是一種開放標準協議，在不暴露用戶密碼的情況下，安全地訪問用戶的資源。常應用於第三方應用需要訪問用戶數據的情況，可以是網頁或者APP中進行存取私人資料方式，OAuth協議在第三方供應商與使用者帶來了以下好處：

- 增加使用者體驗，無需做繁瑣註冊尤其在APP應用程式達到非常好的效果
>例子：剛下載一個APP卻可用Google、Line、Facebook登入，增加使用者體驗

- 以第三方應用帶來用戶資料與提高用戶在第三方服務存留率
>例子：當使用者用Google來登入APP應用程式，可以收集使用者一些私人資訊，並強化Google存留率，因為裝置已經與Google帳號做綁定

- 有利於第三方應用社交相關服務的推廣
>例子：因為大多APP都可用Google登入，所以可能會讓使用者即使沒有Google帳號也會因要使用APP而註冊，同時Google能增加自己社群服務人數

OAuth 2.0 的推出是為了解決開發人員在使用 OAuth 1.0 時面臨的許多痛點，包括複雜的簽章和對非瀏覽器應用程式的支援不佳。

## Role
RFC 6749中，提到OAuth2.0有四個角色分別為：

- resource owner(可授權角色)
資源所有者決定是否授權某個第三方應用程式訪問他們的資源，其實就是指使用者
>例子：像是在APP用Google登入其他APP時會有是否要讓他人存取資源的彈窗

- resource server(第三方供應商)
客戶端通過 OAuth 2.0 流程，獲取並使用授權碼或令牌來訪問資源所有者的資源。
>例子：常見有Google、Meta、X保存使用者resource者

- client(應用程式)
Client是請求訪問資源的應用程式，它是 OAuth 2.0 流程中的實際請求方。客戶端通常是代表資源所有者的第三方應用程式。

- authorization server
authorization server負責驗證資源所有者的身份，並向Client發放authorization code 或存取Token 。它管理授權的過程。

| 角色 | 描述 | 例子 |
|--------------------|--------------------------------------------------------------|--------------------------------------------------------------|
| **Resource Owner** | 資源所有者，通常是使用者，授權第三方應用程式訪問其受保護的資源。 | 使用者在 Google 登入時彈出的授權框，讓用戶選擇是否讓應用程式存取其 Google 帳號中的資料。 |
| **Resource Server** | 存儲和管理使用者資源的伺服器，並處理來自客戶端的授權請求。 | Google、Meta、X 等服務商提供的儲存使用者資料的伺服器。 |
| **Client** | 代表資源所有者發送請求的應用程式，必須經過授權才能訪問資源。 | 一個第三方應用程式（例如日曆應用程式）希望訪問使用者的 Google 硬碟數據。 |
| **Authorization Server** | 驗證資源所有者並發行授權碼或存取令牌的伺服器。 | Google OAuth 伺服器，負責發行授權碼並交換為存取令牌。 |

## OAuth2 Authentication Flow
OAuth2 的身份驗證流程是一種機制，用於驗證使用者身分並授權應用程式存取使用者資源

整體流程流程(Authorization Code Grant)：

- 使用者存取客戶端，客戶端將使用者引導至Authorization Service。

- 使用者在Authorization Service登入並同意授權，授權伺服器返回授權碼（Authorization Code）給客戶端。

- 用戶端使用Authorization Code向Authorization Service請求Access Token(PKCE)。

- 授權伺服器Authorization Code並傳回access token。使用access token存取資源伺服器。
https://ithelp.ithome.com.tw/m/articles/10277215

以下以Google Dirver為例子，來講述OAuth2.0 Authentication Flow，實際Google OAuth2細節可能要參考Google官方document，這邊講述個大概OAuth2.0 Authentication Flow

1. Resource Onwer，進入Applaction的login頁面時，會顯示第三方登入Button，選擇登入的第三方login 將會從OAuth Service返回 login page

2. 返回login page Resource Owner會輸入帳號密碼或者其他登入方式進行登入，登入後會詢問資源consent page來同意授權，同意授權完後OAuth Service會return authentication code

3. 接著需要拿authentication code來交換accesstoken與refresh token

4. 取得access token 與refresh token後，就可以針對授權資源做操作了


## Grant Types
OAuth 2.0定義了四種授權類型(Grant Types)，前文所提的是最常見的Authorization Code Grant，而每種適用於不同場景以及授權方式：

### Authorization Code Grant with PKCE
最常見Grant Types，也相較其他Grant Types安全性較好一點，因為通常會在後端做處理整個Authentication Flow取得Access Token，且對於取得Access Token透過Authorization Code來與OAuth Service來取得相較安全