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
15
Docker Escape@HackerSir StudyGroup
yukai0xe
0
34
How to use Docker@HackerSir 11th
yukai0xe
0
20
Discord Bot Junior Tutorial@HackerSir 11th
yukai0xe
0
10
XSS Everywhere@HackerSir 11th
yukai0xe
0
14
不要小看我的情報網_上吧網路爬蟲!!@HackerSir 11th
yukai0xe
0
28
Featured
See All Featured
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
35
2.4k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Automating Front-end Workflow
addyosmani
1370
200k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
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