OAuth、JWT、OWASP top10

tags: RD1

目錄

• OAuth、JWT、OWASP top10
  • OAuth
    • 關於 Open Authorization
    • 歷史
    • 抽象概念流程圖
    • 核發流程 Grant Type Flow
    • (補充)HTTP 認證出示 token 的三種方式
    • Bearer Token
    • OAuth vs. OpenID Connect
  • JWT
    • 結構
    • 組成
    • JWS (簽章) vs. JWE (加密)
    • 使用者驗證的比較
    • OWASP Top10
    • 參考資料

OAuth

關於 Open Authorization

是一種授權給第三方服務的開放標準，
在使用者不提供密碼的情況下，令第三方服務可以存取使用者(特定範圍內)的帳戶資訊

歷史

• 2006: Twitter 的開發者首倡
• 2007: OAuth Core 1.0
• 2010: OAuth 1.0 Protocol 協定
• 2012: OAuth 2.0 Framework 框架
  • 特點：授權流程標準化，提高安全性並得到廣泛採用（如fb google）

OAuth2.0 與 1.0 互不相容，在2.0框架中可以包涵很多協定來做規範

抽象概念流程圖

+--------+                               +---------------+
|        |--(A)- Authorization Request ->|   Resource    |
|        |                               |     Owner     |
|        |<-(B)-- Authorization Grant ---|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server    |
|        |<-(D)----- Access Token -------|               |
|        |                               +---------------+
|        |
|        |                               +---------------+
|        |--(E)----- Access Token ------>|    Resource   |
|        |                               |     Server    |
|        |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

                Figure 1: Abstract Protocol Flow

角色解說

角色	說明	比如
Resource Owner	資源擁有者	擁有fb帳號的你我
Resource Server	資源伺服器	掌握使用者資料的fb
Client	用戶端（第三方服務）	需要存取你fb資料作為資源的程式
Authorization Server	授權伺服器	fb的獨立授權伺服器

流程解說

A . 用戶端向資源擁有者請求授權

B . 資源擁有者授權用戶端可以去取得 Access Token 來存取受保護資源

C . 用戶端要認證自己並出示 Authorization Grant 來向授權伺服器換取 Access Token

D . 授權伺服器認證用戶端並驗證 Authorization Grant，
. . . 如果都合法，就核發 Access Token

E . 用戶端出示 Access Token 向資源伺服器請求 Protected Resource

F . 資源伺服器驗證 Access Token ，如果合法就處理該請求

Refresh Token

• 如現有的 Access Token 過期而無效或是權限不足，需要再次取得 Token 時，就可以拿取 Refresh Token 向授權伺服器換新的 Access Token
• 不需要再次經過使用者的授權
• 若授權伺服器選擇可核發 Refresh Token ，必須在核發 Access Token 時一併核發
• 新的 Access Token 時效和權限可能會比之前的少
• Refresh Token 不應該被提交到資源伺服器端

+--------+                                           +---------------+
|        |--(A)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(B)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(C)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(D)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(E)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(F)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(G)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(H)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

        Figure 2: Refreshing an Expired Access Token

核發流程 Grant Type Flow

1. Authorization Code
2. Implicit
3. Password Credentials
4. Client Credentials

(補充)HTTP 認證出示 token 的三種方式

1. 放在 Header 裡

Authorization: <type> <credentials>

2. 放在 Request Body 裡
   用表單POST
   

3. 放在 URL 裡
   ex. 中央氣象局api

Bearer Token

解釋

一種協定（RFC 6750）用來搭配OAuth2.0傳輸，示範了一種向資源端傳輸 Access Token 的方法

用法

Authorization: Bearer + base64(code) //in header

OAuth vs. OpenID Connect

兩者的機制大致相同

• OAuth 的目的是授權（Authorization）
• OIDC 目的是認證（Authentication）

JWT

是一種符合 Stateless 之產生token的方法，可以 Bearer 做傳送
用於認證(如類似Session使用者認證)、授權以及資料交換

結構

分為三個部分 header / payload / signature

header

• JSON 格式
• 定義 Token 種類
• 定義其雜湊演算法

{
    “alg” :  “HS256”   //對稱式加密
    “typ” :  “JWT” 
}

payload

• JSON 格式
• 放置所要傳達的資訊
• 放置 registered claims
  • iss：發行方
  • aud：預期接收者
  • sub：聲明用於特定應用程序
  • iat：發行時間
  • exp：到期時間（以UNIX時間格式載）

{   
    “id” :  “1”
    “name” :  “Esther”  

    “exp” :  1601979022   
}

切勿放置隱私資訊於其中，因base64編碼能夠被輕易地轉換出來

signature

• 經由 Header 中所載之演算法處理

HMACSHA256（
    base64Encode(header) + "." +
    base64Encode(payload),
    "256-bit-secret key"    //可先base64處理
）

組成

以 "." 分割成三個部分的字串

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJpZCI6IjEiLCJuYW1lIjoiRXN0aGVyIiwiaXNzIjoidGVzdC5teXNlbGYiLCJleHAiOjE2MDE5NzkwMjJ9.
Xv6AoLX-36GJv_hSobM8_iOCxQxfFTmZFmXGLnYxbRY

分別代表 base64(header + payload) + signature

除非知道密鑰值，否則若直接修改payload內容，會在與signature驗證時因不一致被擋下來。

JWS (簽章) vs. JWE (加密)

若使用非對稱式加密
隨著公私鑰持有方的不同，數據的流動方向和方式就分為了兩種

參考資料

使用者驗證的比較

JWT 驗證

• 優點：伺服器不需花費Session成本
• 缺點：失去對使用者的掌控權，無法隨時註銷某用戶直到其token過期

Cookie-based session 驗證

• 優點：資料方便統一管理
• 缺點：Cookie 易被竄改、資料庫成本隨著用戶增加提高，每次驗證需經資料庫查詢耗費效能

OWASP Top10

我懶得整理了ＸＤＤ

參考資料

[1] OWASP Top 10 Security Risks & Vulnerabilities
[2] 開發者必備知識 - HTTP認證（HTTP Authentication）