kyoto tech talk #9

Transcript

1. 2025.12.5 「なぜ動かない？」からの脱却！OAuth 2.0認可のエラー原因を特定しやすくした話
2. Money Forward, Inc. 2 Index 01 自己 紹介 02 目的 03 OAuth2.0の概要 04 抱えていた課題 05 解決アプローチ 06 成果とまとめ
3. Money Forward, Inc. 3 自己紹介 01
4. Money Forward, Inc. 4 Senba Taichi 出身：大阪府 所属：京都大学工学部2年 業務内容：API認可基盤の開発 趣味：芸人のラジオを聴くこと （マユリカ、ダイアンがお気に入り） ガジェット集め （Apple、Ankerが好きです） MFBC> Business Platform Dev> API推進部> 長期インターン
5. Money Forward, Inc. 5 目的 02
6. Money Forward, Inc. 6 目的と対象 目的 OAuth2.0の認可フローの概要を理解してもらうこと OAuth2.0の認可フローでつまづきやすいところを改善して開発者 体験を向上させた経験から学んだことを共有すること 対象者 webAPI を開発している・利用しているエンジニアの方 API認可の仕組みに興味のあるエンジニアの方
7. Money Forward, Inc. 7 OAuth2.0の概要 03
8. 認証 リソースへのアクセスを許可する前に、ユーザーの身元を確認するプロセス （例: パスポート提示のように「身元を確認する」プロセス） 認可 リソースに対するユーザーのアクセス権限を確認するプロセス （例: ビザ提示のように「入国の権限を確認する」プロセス）
9. 認証 リソースへのアクセスを許可する前に、ユーザーの身元を確認するプロセス （例: パスポート提示のように「身元を確認する」プロセス） 認可 リソースに対するユーザーのアクセス権限を確認するプロセス （例: ビザ提示のように「入国の権限を確認する」プロセス） https://x.com/a03/status/1995841074162700718?s=20
10. OAuth2.0の詳細 OAuth 2.0 認可フレームワークは、サードパーティのアプリ ケーションが、リソースオーナーと HTTP サービス間の承認の やり取りを調整することによってリソースオーナーに代わって、 またはサードパーティのアプリケーションがそれ自身の代理と してアクセスを取得することを許可することによって、HTTP サービスへの限定的なアクセスを取得することを可能にします 出典: RFC 6749
11. トークンを用いた権限の委譲
12. Money Forward, Inc. 12 OAuth2.0認可フレームワークの登場人物 リソースオーナー 認可サーバー クライアント リソースサーバー ユーザーがリソースサーバーにアクセスさせた いアプリケーション サードパーティのwebアプリケーション リソースオーナー認可を得て、クライアント にアクセストークン を発行するサーバー 保護されたリソースをホストするサーバー 主としてWebAPI リソースの持ち主。サーバーへのアクセスを 許可する能力を持つ人
13. 請求書を発行する ために会計情報を 取得したい 会計情報を取得 ① クライアント リソースオーナー 認可サーバー リソースサーバー
15. 認可エンドポイントへ リクエストを送る ② クライアント リソースオーナー 認可サーバー リソースサーバー
16. ③認可しますか？ クライアント リソースオーナー 認可サーバー リソースサーバー
17. ③認可して大丈夫 ④大丈夫！
19. ④許可！ クライアント リソースオーナー 認可サーバー リソースサーバー
20. ⑤認可コードを与える クライアント リソースオーナー 認可サーバー リソースサーバー
21. ⑥クライアントはトークンエ ンドポイントに認可コードを 提示する クライアント リソースオーナー 認可サーバー リソースサーバー
22. ⑦アクセストークンを 与える ⑧アクセストークンと共 にwebAPIを叩く クライアント リソースオーナー 認可サーバー リソースサーバー
23. ⑨このアクセストークンは 有効？ ⑩有効or無効 ⑪ ⑩に応じて結果を返す クライアント リソースオーナー 認可サーバー リソースサーバー
24. Money Forward, Inc. 24 抱えていた課題 04
25. Money Forward, Inc. 25 OAuth2.0認可フレームワークの登場人物 リソースオーナー 認可サーバー クライアント リソースサーバー ユーザーがリソースサーバーにアクセスさせた いアプリケーション サードパーティのwebアプリケーション リソースオーナー認可を得て、クライアント にアクセストークン を発行するサーバー 保護されたリソースをホストするサーバー 主としてWebAPI リソースの持ち主。サーバーへのアクセスを 許可する能力を持つ人
26. 認可エンドポイントへ リクエストを送る この時にエラーがよく起こっていた クライアント リソースオーナー 認可サーバー リソースサーバー
27. 開発者は以下のパラメータを含めたリクエストを送るようにしなければいけない https://api.biz.moneyforward.com/authorize?response_type=code&client_id=${ClientID}&s cope=mfc/admin/tenant.read&redirect_uri=http://localhost:12345/callback response_type 認可コードフローであることを示す「 code」が設定さ れる client_id クライアント登録時に払い出されるクライアント ID scope アプリが要求するリソースアクセスの範囲 redirect_uri クライアント登録時に設定したリダイレクト URI
28. 仮にサードパーティーアプリケーションの開発者が間違えたURLで リクエストを送った場合 どのパラメータが間違っているのかor入れ忘れているのか、わからない
29. クライアントの開発者 • エラーの詳細がわからないので解決に時間がかかるので開発スピードが低下 カスタマーサポート & 運用者（私たち） • 原因不明のエラーに対する問い合わせを解決するためのログ調査に工数を 割かれる
30. Money Forward, Inc. 30 解決アプローチ 05
31. クライアント リソースオーナー 認可サーバー リソースサーバー
32. Authleteにrequestを送ってその返信を見て判断 Authleteから帰ってくるレスポンス(json)
35. Money Forward, Inc. 35 成果とまとめ 06
36. 成果 • 開発者体験の向上 ◦ 詳細なエラー内容を伝えることで開発者はエラーをもとに 自己解決できるようになった • サポートコストの削減の可能性 ◦ 原因不明のエラーに対するカスタマーサポートへの問い合 わせの減少すると考えている
38. まとめ • OAuth2.0の認可フレームワークとは ◦ トークンを用いた権限委譲の仕組み • 技術的アプローチ ◦ 検証をOAuth2.0に特化したAuthleteに任せることで コードベースへの変更を少なく改善することができた
39. • エラーメッセージの意義 ◦ エラーメッセージは、単に「事実」を伝えるためのもので はない ◦ エラーを見た相手に「ネクストアクション」を促し、解決 へ導くためのものである
40. 『プロダクト開発meetup関西#12 @Osaka Tech Lab』 やります！ プロダクト開発 meetup関西#12（来週開 催！！！） 開催日: 12月12日（金） 時間: 18:50〜21:00 形式: Open Space Technology 会場: Osaka Tech Lab(KINTOテクノロジーズ株式 会社) 住所:大阪府大阪市北区梅田3丁目1番3号 ノース ゲートビルディング 20F https://maps.app.goo.gl/Fcbwb9DCJMdsAa 2T6 イベントページ : https://product-dev-meetup-kansai.connp ass.com/event/376009/