Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OAuth2.0 Easy Talk@HackerSir StudyGroup
Search
YUKAI
May 30, 2025
0
7
OAuth2.0 Easy Talk@HackerSir StudyGroup
YUKAI
May 30, 2025
Tweet
Share
More Decks by YUKAI
See All by YUKAI
WebAssembly 入門:在 Browser 上跑 C Code 是怎麼回事@HackerSir StudyGroup
yukai0xe
0
7
Docker Escape@HackerSir StudyGroup
yukai0xe
0
12
How to use Docker@HackerSir 11th
yukai0xe
0
9
Discord Bot Junior Tutorial@HackerSir 11th
yukai0xe
0
9
XSS Everywhere@HackerSir 11th
yukai0xe
0
5
不要小看我的情報網_上吧網路爬蟲!!@HackerSir 11th
yukai0xe
0
9
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Designing for humans not robots
tammielis
253
25k
Why You Should Never Use an ORM
jnunemaker
PRO
56
9.4k
It's Worth the Effort
3n
184
28k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
How STYLIGHT went responsive
nonsquared
100
5.6k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Code Reviewing Like a Champion
maltzj
524
40k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.6k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
860
Transcript
OAuth2.0 By YuKAi 2024.12.05
Why OAuth 01 OAuth2.0 02 Grant Type 03 Outline
Why OAuth 01
• 用來處理有關「Authorization」的開發標準 • 允許第三方應用程式存取另一個應用程式上的資源 • 第三方不會紀錄使用者的帳密 • OAuth1.0(RFC 5849)、OAuth2.0 (RFC
6749) Why OAuth
• OAuth1.0 • 每次請求都要加密簽名 • 實現上較為複雜 • Token:Reqeust Token、Access Token,都需要進行簽名驗證
• 只設計給 web browser 使用 OAuth1.0 的問題
• OAuth2.0 • 簡化了 1.0 的流程,不需要每次請求簽名 • 提供多種授權方式(Grant Type) •
Token:Access Token 、 Refresh Token OAuth2.0 改善了什麼
OAuth2.0 02
• Resource Owner:能夠授權存取權限的角色,也就是使用者 • Resource Server:存放資源的 Server • Authorization Server:負責驗證身分的
Server • Client:發出 OAuth 授權請求的應用程式 Roles Resource Owner Client Resource Server Authorization Server
• Client ID:第三方應用的 ID • Client Secert:第三方應用的密鑰 • Redirect URL:
Authorization Server 成功驗證後要把資料打回去的 API, 通常是第三方應用的 Server API • Grant Type:授權方式 • Access Token:流程跑完最後用來取得 Resource 的 Token KeyWords
OAuth2.0 Flow
• Case1:Next.js + NextAuth • Google OAuth • Github OAuth
• Case2:Node.js + googleapis • Google OAuth • Resource:google developer doc OAuth2.0 Flow 實際情況
Case1:Authorization Request
• Authorization Server 會把 Code 以 Query String 打回 App
Server 的 redirect URL • 接下來會在 Server 做 code 和 token 的交換 Case1: Authorization Grant
Case1: Access Token • 在 Server 的 redirect URL 完成了
Code 和 Access Token,可以發現 response cookies 多了個 session-token
Case2: Access Token ??How?
追 Repo 找到這個:googleapis Case2: Access Token
Grant Type 03
• Authorization Code Flow(Code -> Access Token) • Implicit Flow
with Form Post(直接拿到 Access Token) • Resource Owner Password Flow(驗證過程變成在 Client 上) • Client Credentials Flow Grant Type
• 應用程式主要在前端執行 • 安全性較脆弱 • 應用:SPA、靜態網站 Implicit Flow with Form
Post
• 由 Client 處理驗證 • 有可能帳號密碼會被記錄 • 需要為高信賴度的應用程式 • 應用:內部系統
Resource Owner Password Flow
• Resource Owner 與 Client 的角色重疊 • 拿取 Client 相關的資源
• 應用:M2M Applications Client Credentials Flow
None