kyoto tech talk #9 - Speaker Deck

kyoto tech talk #9

by TaichiSenba

Embed

Start on current slide

Slide 1

Slide 1 text

2025.12.5 「なぜ動かない？」からの脱却！OAuth 2.0認可のエラー原因を特定しやすくした話

Slide 2

Slide 2 text

Money Forward, Inc. 2 Index 01 自己紹介 02 目的 03 OAuth2.0の概要 04 抱えていた課題 05 解決アプローチ 06 成果とまとめ

Slide 3

Slide 3 text

Money Forward, Inc. 3 自己紹介 01

Slide 4

Slide 4 text

Money Forward, Inc. 4 Senba Taichi 出身：大阪府所属：京都大学工学部2年業務内容：API認可基盤の開発趣味：芸人のラジオを聴くこと（マユリカ、ダイアンがお気に入り）ガジェット集め（Apple、Ankerが好きです） MFBC> Business Platform Dev> API推進部> 長期インターン

Slide 5

Slide 5 text

Money Forward, Inc. 5 目的 02

Slide 6

Slide 6 text

Money Forward, Inc. 6 目的と対象目的 OAuth2.0の認可フローの概要を理解してもらうこと OAuth2.0の認可フローでつまづきやすいところを改善して開発者体験を向上させた経験から学んだことを共有すること対象者 webAPI を開発している・利用しているエンジニアの方 API認可の仕組みに興味のあるエンジニアの方

Slide 7

Slide 7 text

Money Forward, Inc. 7 OAuth2.0の概要 03

Slide 8

Slide 8 text

認証リソースへのアクセスを許可する前に、ユーザーの身元を確認するプロセス（例: パスポート提示のように「身元を確認する」プロセス）認可リソースに対するユーザーのアクセス権限を確認するプロセス（例: ビザ提示のように「入国の権限を確認する」プロセス）

Slide 9

Slide 9 text

認証リソースへのアクセスを許可する前に、ユーザーの身元を確認するプロセス（例: パスポート提示のように「身元を確認する」プロセス）認可リソースに対するユーザーのアクセス権限を確認するプロセス（例: ビザ提示のように「入国の権限を確認する」プロセス） https://x.com/a03/status/1995841074162700718?s=20

Slide 10

Slide 10 text

OAuth2.0の詳細 OAuth 2.0 認可フレームワークは、サードパーティのアプリケーションが、リソースオーナーと HTTP サービス間の承認のやり取りを調整することによってリソースオーナーに代わって、またはサードパーティのアプリケーションがそれ自身の代理としてアクセスを取得することを許可することによって、HTTP サービスへの限定的なアクセスを取得することを可能にします出典: RFC 6749

Slide 11

Slide 11 text

トークンを用いた権限の委譲

Slide 12

Slide 12 text

Money Forward, Inc. 12 OAuth2.0認可フレームワークの登場人物リソースオーナー認可サーバークライアントリソースサーバーユーザーがリソースサーバーにアクセスさせたいアプリケーションサードパーティのwebアプリケーションリソースオーナー認可を得て、クライアントにアクセストークンを発行するサーバー保護されたリソースをホストするサーバー主としてWebAPI リソースの持ち主。サーバーへのアクセスを許可する能力を持つ人

Slide 13

Slide 13 text

請求書を発行するために会計情報を取得したい会計情報を取得 ① クライアントリソースオーナー認可サーバーリソースサーバー

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

認可エンドポイントへリクエストを送る ② クライアントリソースオーナー認可サーバーリソースサーバー

Slide 16

Slide 16 text

③認可しますか？クライアントリソースオーナー認可サーバーリソースサーバー

Slide 17

Slide 17 text

③認可して大丈夫 ④大丈夫！

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

④許可！クライアントリソースオーナー認可サーバーリソースサーバー

Slide 20

Slide 20 text

⑤認可コードを与えるクライアントリソースオーナー認可サーバーリソースサーバー

Slide 21

Slide 21 text

⑥クライアントはトークンエンドポイントに認可コードを提示するクライアントリソースオーナー認可サーバーリソースサーバー

Slide 22

Slide 22 text

⑦アクセストークンを与える ⑧アクセストークンと共にwebAPIを叩くクライアントリソースオーナー認可サーバーリソースサーバー

Slide 23

Slide 23 text

⑨このアクセストークンは有効？ ⑩有効or無効 ⑪ ⑩に応じて結果を返すクライアントリソースオーナー認可サーバーリソースサーバー

Slide 24

Slide 24 text

Money Forward, Inc. 24 抱えていた課題 04

Slide 25

Slide 25 text

Money Forward, Inc. 25 OAuth2.0認可フレームワークの登場人物リソースオーナー認可サーバークライアントリソースサーバーユーザーがリソースサーバーにアクセスさせたいアプリケーションサードパーティのwebアプリケーションリソースオーナー認可を得て、クライアントにアクセストークンを発行するサーバー保護されたリソースをホストするサーバー主としてWebAPI リソースの持ち主。サーバーへのアクセスを許可する能力を持つ人

Slide 26

Slide 26 text

認可エンドポイントへリクエストを送るこの時にエラーがよく起こっていたクライアントリソースオーナー認可サーバーリソースサーバー

Slide 27

Slide 27 text

開発者は以下のパラメータを含めたリクエストを送るようにしなければいけない 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

Slide 28

Slide 28 text

仮にサードパーティーアプリケーションの開発者が間違えたURLでリクエストを送った場合どのパラメータが間違っているのかor入れ忘れているのか、わからない

Slide 29

Slide 29 text

クライアントの開発者 ● エラーの詳細がわからないので解決に時間がかかるので開発スピードが低下カスタマーサポート & 運用者（私たち） ● 原因不明のエラーに対する問い合わせを解決するためのログ調査に工数を割かれる

Slide 30

Slide 30 text

Money Forward, Inc. 30 解決アプローチ 05

Slide 31

Slide 31 text

クライアントリソースオーナー認可サーバーリソースサーバー

Slide 32

Slide 32 text

Authleteにrequestを送ってその返信を見て判断 Authleteから帰ってくるレスポンス(json)

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

Money Forward, Inc. 35 成果とまとめ 06

Slide 36

Slide 36 text

成果 ● 開発者体験の向上 ○ 詳細なエラー内容を伝えることで開発者はエラーをもとに自己解決できるようになった ● サポートコストの削減の可能性 ○ 原因不明のエラーに対するカスタマーサポートへの問い合わせの減少すると考えている

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

まとめ ● OAuth2.0の認可フレームワークとは ○ トークンを用いた権限委譲の仕組み ● 技術的アプローチ ○ 検証をOAuth2.0に特化したAuthleteに任せることでコードベースへの変更を少なく改善することができた

Slide 39

Slide 39 text

● エラーメッセージの意義 ○ エラーメッセージは、単に「事実」を伝えるためのものではない ○ エラーを見た相手に「ネクストアクション」を促し、解決へ導くためのものである

Slide 40

Slide 40 text

『プロダクト開発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/

Slide 41

Slide 41 text

No content