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
19
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
17
Docker Escape@HackerSir StudyGroup
yukai0xe
0
38
How to use Docker@HackerSir 11th
yukai0xe
0
20
Discord Bot Junior Tutorial@HackerSir 11th
yukai0xe
0
10
XSS Everywhere@HackerSir 11th
yukai0xe
0
18
不要小看我的情報網_上吧網路爬蟲!!@HackerSir 11th
yukai0xe
0
34
Featured
See All Featured
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Gamification - CAS2011
davidbonilla
81
5.4k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
How to train your dragon (web standard)
notwaldorf
96
6.1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Automating Front-end Workflow
addyosmani
1370
200k
We Have a Design System, Now What?
morganepeng
53
7.7k
Rails Girls Zürich Keynote
gr2m
95
14k
Code Review Best Practice
trishagee
69
19k
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