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/OpenID Connect
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Yuki Watanabe
June 21, 2023
Programming
520
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
基礎からわかろうOAuth2/OpenID Connect
Yuki Watanabe
June 21, 2023
More Decks by Yuki Watanabe
See All by Yuki Watanabe
【つよナレ#1】初心者こそバニラなPHPでWebアプリを作るべき
ukwhatn
0
430
15分間でふんわり理解するDocker @ Matsuriba MAX
ukwhatn
1
600
10分間でエンジニア就活について話す #ニックトレイン
ukwhatn
3
1.4k
[KC3 Meet! vol.1]ちょっとだけわかるPasskey
ukwhatn
2
480
データベース入門(数珠つなぎオンライン勉強会 #03)
ukwhatn
1
310
バックエンドロードマップ(数珠つなぎオンライン勉強会 #02)
ukwhatn
0
640
サーバ入門(概論〜Webサーバ構築)
ukwhatn
0
500
Other Decks in Programming
See All in Programming
タクシーアプリ『GO』の バックエンド開発のおける AI利活用と若者のすべて
pyama86
3
2k
AutonomyとControlのあいだ:Graflowで記述するAIエージェント協調
myui
0
120
Spec Driven Development | AI Summit Lisbon
danielsogl
PRO
0
180
Lessons from Spec-Driven Development
simas
PRO
0
170
Spring Security 実践 ─ GraphQL APIで実務に役立つ 認証・認可 を学ぶ
wagyu
0
210
OSもどきOS
arkw
0
480
Webフレームワークの ベンチマークについて
yusukebe
0
160
Developing with AI Agents — Codex, Claude Code & Cowork Practical Guide
x5gtrn
PRO
0
1.2k
ユニットテストの先へ:テスト技法で要求・仕様を整理するJava開発実践 / Beyond_Unit_Testing_Practical_Java_Development_Techniques_for_Organizing_Requirements_and_Specifications
shimashima35
0
390
Modding RubyKaigi for Myself
yui_knk
0
920
AI時代のUIはどこへ行く?その2!
yusukebe
21
7k
運用エージェントは "作る" から "育てる" へ - 記憶と自己進化の3層設計パターン / self-evolving-agents-three-layer-agent-design
gawa
12
3.6k
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Designing for humans not robots
tammielis
254
26k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
210
Prompt Engineering for Job Search
mfonobong
0
340
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.5k
The agentic SEO stack - context over prompts
schlessera
0
810
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
580
Google's AI Overviews - The New Search
badams
0
1k
YesSQL, Process and Tooling at Scale
rocio
174
15k
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
130
The browser strikes back
jonoalderson
0
1.2k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Transcript
基礎からわかろう OAuth2/OpenID Connect Yuki Watanabe (@ukwhatn)
SPEAKER • 渡邉 雄貴 / Yuki Watanabe ◦ 近畿大学 理工学部
B3 ▪ KINDAI Info-Tech HUB 役員 ▪ KC3運営委員会(NPO法人NxTEND) 理事 ◦ Webバックエンド・インフラエンジニア ▪ 長期インターンシップ・業務委託での開発 ▪ 転職型プログラミングスクール メンター
SPEAKER • 渡邉 雄貴 / Yuki Watanabe ◦ SKILLS ▪
Webバックエンド • Ruby(Rails) / Python(FastAPI, Flask) / Kotlin / TS ▪ Webフロントエンド • TS(React) / JS / HTML-CSS ▪ インフラ・その他 • Linux / AWS / Docker / DB / 認証・認可
SPEAKER • 渡邉 雄貴 / Yuki Watanabe ◦ SKILLS ▪
Webバックエンド • Ruby(Rails) / Python(FastAPI, Flask) / Kotlin / TS ▪ Webフロントエンド • TS(React) / JS / HTML-CSS ▪ インフラ・その他 • Linux / AWS / Docker / DB / 認証・認可
もくじ 認証・認可の違い 認証・認可警察に 見つからないための基礎知識 01 OpenID Connect OIDCはどう安全なのか? 04 OAuth2とは?
OAuth2の具体的な仕様・フロー 02 OAuth2認証 OAuth2を認証に使うということ 03
認証・認可の違い
認証ってなに? • 認証/Authentication(Authn) ◦ サービスの利用者が本人であることを確認する ▪ What you are •
生体認証 ▪ What you have • 所有物認証(カギやセキュリティキーなど) ▪ What you know • 知識認証(パスワード・秘密の質問) 認証・認可の違い
認証ってなに? • 認証/Authentication(Authn) ◦ サービスの利用者が本人であることを確認する ▪ What you are •
生体認証 ▪ What you have • 所有物認証(カギやセキュリティキーなど) ▪ What you know • 知識認証(パスワード・秘密の質問) 認証・認可の違い
認可ってなに? • 認可/Authorization(Authz) ◦ サービスの利用者に適切な権限を与える仕組み ▪ リソースへのアクセス権限・操作権限など ▪ 外部サービスに対して操作を許可することが多い •
Twitterへの代理投稿 • メールのRead/Write 認証・認可の違い
認可ってなに? • 認可/Authorization(Authz) ◦ サービスの利用者に適切な権限を与える ▪ リソースへのアクセス権限・操作権限など ▪ 外部サービスに対して操作を許可することが多い •
Twitterへの代理投稿 • メールのRead/Write 認証・認可の違い
OAuth2とは?
OAuth2とは? • OAuth2 ◦ 認可(権限委譲)のためのプロトコル ▪ ユーザのリソースへのアクセス権限を外部サービスに移譲 ▪ 外部サービスはユーザの認証情報を知る必要がない •
べんり! • 必要なだけ権限を移譲できる!
OAuth2のしくみ • 登場人物(ロール) ◦ リソースオーナー(ユーザ) ▪ GoogleやTwitterのアカウントオーナーを指す ◦ クライアント ▪
権限を移譲された外部サービス ◦ リソースサーバー ▪ だいたいWebAPIのこと リソースを提供する ◦ 認可サーバー ▪ OAuthサービスを提供するサーバー OAuth2とは?
• 登場人物 ◦ アクセストークン ▪ 「誰の」「どのリソースに」「いつまで」 アクセスできるかと紐付けられている ▪ クライアントからリソースサーバへのアクセスに添付 •
紐付けられた情報と矛盾がなければアクセスを許可 ▪ Bearerトークン(RFC6750) • アクセストークンさえ持っていれば誰でもアクセスできる OAuth2のしくみ OAuth2とは?
• 登場人物 ◦ アクセストークン ▪ スコープ • 「何の」リソースにアクセスできるかを規定 • クライアントから認可サーバへのリクエスト時に指定する
OAuth2のしくみ OAuth2とは? https://discord.com/api/oauth2/authorize?client_id=XXXXX &redirect_uri=http%3A%2F%2Fredirect:3000&response_type=code &scope=identify%20guilds
• 登場人物 ◦ リフレッシュトークン ▪ アクセストークンの再発行に利用される • 必須ではないので、発行されないこともある • 認可サーバに対して送られる
▪ 有効期限が極めて長い • 30日くらいあることもある OAuth2のしくみ OAuth2とは?
• 登場人物 ◦ 認可コード ▪ リソースオーナーが権限委譲に同意した証 ▪ 301リダイレクトによってクライアントへ送られる • クライアントは、認可コードを認可サーバに再送して
アクセストークンを要求する ▪ 有効期限が極めて短い • 仕様では10分以内を推奨 OAuth2のしくみ OAuth2とは?
• エンドポイント ◦ 認可エンドポイント ▪ 認可サーバによって提供 ▪ 認可コードの発行を行う ◦ トークンエンドポイント
▪ 認可サーバによって提供 ▪ 認可コードと引き換えにアクセストークンの発行を行う ▪ クライアントのIdentityはBasic認証で行う OAuth2のしくみ OAuth2とは?
• エンドポイント ◦ リダイレクトエンドポイント ▪ クライアントが提供する ▪ 認可コード発行時に、301リダイレクトが行われる先 OAuth2のしくみ OAuth2とは?
HTTP/1.1 301 Found Location: https://ukwhatn.com/callback?code=xxxxxxxxxx
• 事前登録 ◦ クライアントは、リダイレクトエンドポイントを 各リソース提供サービスに登録する ▪ クライアントIDとシークレットが発行される グラントにおける前提 OAuth2におけるグラントタイプ
• 事前登録 ◦ クライアントは、リダイレクトエンドポイントを 各リソース提供サービスに登録する ▪ それに対応したクライアントIDとシークレットが発行 グラントにおける前提 OAuth2におけるグラントタイプ
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ HTTP/1.1 301 Found Location: https://ninka.example.com/authorize ?response_type=code&client_id=123456 &state=xyz&scope=identity &redirect_uri=https://client.user.com/callback
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ HTTP/1.1 301 Found Location: https://client.user.com/callback?code=xxxxxxxxxx&state=xyz
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ POST /token HTTP/1.1 Host: ninka.example.com Authorization: Basic <CLIENT_SECRET>
Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=xxx &redirect_uri=https://client.user.com/callback POST /token HTTP/1.1 Host: ninka.example.com Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=xxx &redirect_uri=https://client.user.com/callback &client_id=123456&client_secret=<CLIENT_SECRET>
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ HTTP/1.1 200 OK Content-type: application/json;charset=UTF-8 Cache-Control: no-cache Pragma:
no-cache { “access_token”: “abc123”, “refresh_token”: “987zyx”, “expires_in”: 3600, “token_type”: Bearer }
認可コードグラント(認可コードフロー) OAuth2におけるグラントタイプ GET /api/user/1 HTTP/1.1 Host: resource.example.com Authorization: Bearer xyz123
Content-Type: application/x-www-form-urlencoded
クライアントコンフィデンシャルグラント (2-legged OAuth) OAuth2におけるグラントタイプ • つかえるとき ◦ クライアント全体に対してアクセス権限を発行する ◦ クライアントがコンフィデンシャルクライアントである
▪ client secretなどをセキュアに保存できるクライアント
リソースオーナーパスワードクレデンシャルグラント OAuth2におけるグラントタイプ • つかえるとき ◦ 同組織のサービス間での 認可処理
インプリシットグラント OAuth2におけるグラントタイプ
インプリシットグラント OAuth2におけるグラントタイプ
パブリッククライアントにおける認可コードグラント OAuth2におけるグラントタイプ ※ クライアントシークレットを使わないことが許可されている
認可コード横取り攻撃 OAuth2におけるグラントタイプ
認可コードグラント + PKCE • PKCE ◦ Proof Key of Code
Exchange ▪ OAuthの拡張仕様(RFC7636)で定義 OAuth2におけるグラントタイプ
認可コードグラント + PKCE • PKCE ◦ パラメータ ▪ code_verifier •
43-128文字、英数字+[“-” , ”.” , ”_” , “~”] ▪ code_challenge_method • plain(平文) or S256(SHA256) ▪ code_challenge • plainならcode_challengeそのまま • S256なら OAuth2におけるグラントタイプ BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
認可コードグラント + PKCE OAuth2におけるグラントタイプ
認可コードグラント + PKCE OAuth2におけるグラントタイプ
認可コードグラント + PKCE OAuth2におけるグラントタイプ
OAuth2を認証に使うということ
OAuth2を認証に使うということ OAuth2を認証に使う
• 2つの誤解 ◦ ① OAuth2は認証のためのものではない ▪ OAuth2では、リソースへのアクセス制御のために認証を フローの中に組み込んでいますが、 そのためのものではありません OAuth2を認証に使うということ
OAuth2を認証に使う
• 2つの誤解 ◦ ② OAuth2を認証に使っているからって なんでも危険な訳ではない ▪ OAuth2の脆弱性 インプリシットグラントの脆弱性 •
インプリシットグラントでは アクセストークンが直接ブラウザに落ちてくるため ここでの奪取やなりすましが起こりうる OAuth2を認証に使うということ OAuth2を認証に使う
• ただし ◦ 認証に使うなら、ちゃんと認証用途に標準化された OpenID Connectを使ったほうが良い ▪ でもあんまりない • Google,
Microsoft, Yahoo, Paypal, Amazon ……… • 我らがDiscordも提供していない OAuth2を認証に使うということ OAuth2を認証に使う
OpenID Connect
OpenID Connectとは? • OpenID Connect ◦ 仕組み ▪ OAuth2 +
IDトークン + UserInfoエンドポイント ◦ 用語の違い ▪ リソースオーナー -> エンドユーザー ▪ クライアント -> リライング・パーティ(RP) ▪ 認可サーバ -> IDプロパイダ ▪ リソースサーバ -> UserInfoエンドポイント OpenID Connect
認可コードフロー OpenID Connect
認可コードフロー OpenID Connect
• IDトークン ◦ IdPが発行し、RPが受け取る ◦ 形式 ▪ 署名付きJWT ◦ 内容
▪ エンドユーザの識別ID(sub) ▪ 有効期限・発行日時 ▪ 発行者ID・受領者ID ▪ トークンの形式・署名方式・署名 IDトークン OpenID Connect
• 中身 ◦ ヘッダ ▪ typクレーム:”JWT” • JWTであることを表す ▪ algクレーム:”RS256”
• 署名方式を表す • noneは禁止 • 公開鍵は特定の場所で公開(RFC7517) IDトークン OpenID Connect
• 中身 ◦ ペイロード ▪ issクレーム(issuer) • IDトークン発行者(IdPのURLなど) ◦ 正しい発行者であるかを確認
▪ audクレーム(audience) • IDトークンを受け取るRPのクライアントID ◦ 自分のIDトークンであるか(自分宛に発行されたものか)確認 IDトークン OpenID Connect
• 中身 ◦ ペイロード ▪ subクレーム(subject) • エンドユーザのuuid(識別子) ◦ RPがエンドユーザを識別するためのもの
▪ iatクレーム(issued at) • JWTの発行時間(UNIX Time (sec)) ◦ 未来の日時を指していないか確認 IDトークン OpenID Connect
• 中身 ◦ ペイロード ▪ expクレーム(expiration time) • IDトークンの有効期限 ◦
RPはこの期限以降にIDトークンを受け入れてはならない ▪ nonceクレーム • 認証リクエスト時に送ったnonceがそのまま入る ◦ IdPが認可コードと紐づけて保管 ◦ 攻撃者が認可コードをすりかえることを防ぐ IDトークン OpenID Connect
• 中身 ◦ 署名 ▪ f”{ヘッダ}.{ペイロード}”に対して Base64URLエンコード -> 署名 ->
Base64URLエンコード • ここを検証することでJWTの正当性を担保 ◦ たいへんなので各自調べてください • 認証コードフローでは省略しても良い ◦ 改ざんの可能性が限りなく低いため IDトークン OpenID Connect
• UserInfoエンドポイント ◦ ユーザの特定(認証)以外の用途で ユーザ情報を取得したいときに使う ▪ ユーザの識別情報はIDトークンのsubクレームで行う ▪ emailや住所などはこっちで取得する •
scope: openid, profile, email, address, phone • レスポンスのsubとIDトークンのsubの一致を必ず確認 UserInfoエンドポイント OpenID Connect
• インプリシットフロー ◦ パブリッククライアント向けOIDCフロー ▪ 認可コードに関する処理が省かれる • nonceによって OAuth2のインプリシットフロー脆弱性を防止 •
ハイブリッドフロー ◦ バックエンドを持つネイティブアプリ向け ▪ 認可コードとアクセストークンがアプリに送られ、 トークンは保存、認可コードはバックエンドに送られる その他のフロー OpenID Connect
まとめ OAuth認証は標準化されておらず、不便な部分も 01 OIDCは認証のためのプロトコル(標準化済) 02 OIDCの根幹はIDトークンの検証とnonceにある 03 OAuth2は認可のためのプロトコルである 04 インプリシットフロー以外は認証にも(一応)使える
05
参考資料 • The OAuth 2.0 Authorization Framework ◦ © 2012
IETF Trust, Dick Hardt ◦ https://datatracker.ietf.org/doc/html/rfc6749 • The OAuth 2.0 Authorization Framework: Bearer Token Usage ◦ © 2012 IETF Trust, Michael B. Jones, Dict Hardt ◦ https://datatracker.ietf.org/doc/html/rfc6750 • The OAuth 2.0 Threat Model and Security Considerations ◦ © 2013 IETF Trust, Torsten Lodderstedt, Mark McGloin, Phil Hunt ◦ https://datatracker.ietf.org/doc/html/rfc6750
参考資料 • OpenID Connect Core 1.0 incorporating errata set 1
◦ © 2014 The OpenID Foundation ◦ http://openid-foundation-japan.github.io/openid-connect-core-1_ 0.ja.html • OpenID Connect Implicit Client Implementer's Guide 1.0 - draft 2 ◦ © 2015 The OpenID Foundation ◦ http://openid-foundation-japan.github.io/openid-connect-implicit- 1_0.ja.html
参考資料 • 雰囲気でOAuth2.0を使っているエンジニアが OAuth2.0を整理して、手を動かしながら学べる本 ◦ © 2019 Auth屋 • OAuth、OAuth認証、OpenID
Connectの違いを整理して、 理解できる本 ◦ © 2019 Auth屋 • OAuth・OIDCへの攻撃と対策を整理して理解できる本 ◦ © 2020 Auth屋