![見出し画像](https://assets.st-note.com/production/uploads/images/118128006/rectangle_large_type_2_66310d9a42fe226cb58b8eb81b7340b2.png?width=1200)
OAuth:「引換券」から「トークン」に交換してららおう!認可コードグラント
どうも、こんにちは!前回記事の続きです。ユーザに代わって、アプリが別サービスのAPIを利用できるようにする枠組み「OAuth」についてご紹介しています!
前回は、認可コードグラントの流れ図を途中まで紹介しました。クライアントアプリが認可サーバから「認可コード」をゲットできましたね。ただし、それは「引き換え券」であって、これを使ってAPIのリソースにはアクセスできません…。
![](https://assets.st-note.com/img/1696536602066-RLYufkZQnV.png)
今回は、その続き、クライアントアプリが、認可コードを使ってアクセストークンを取得するところまでやりましょう!
では、いってみよう!
認可コードを受け取った後の手順
では、⑦から再スタートです!
![](https://assets.st-note.com/img/1696540773156-ZwQTEmFDSW.png?width=1200)
7.アクセストークンをリクエストする
引換券…もとい「認可コード」を受け取ったクライアントアプリさんは、その「認可コード」をHTTPリクエストという形で認可サーバに送りかえします。「こんどこそ、アクセストークンをください!」とね。
![](https://assets.st-note.com/img/1696538237542-Onuz6owfzl.png)
このトークンリクエストについて、もう少し補足しましょう。
アクセストークンの要求先は、認可サーバの「トークンエンドポイント」となります。他方、認可コードの要求先は、認可サーバの「認可エンドポイント」です。何が違うか?私もよく分かりません(汗)。
とりあえず、「認可コード要求とアクセスコード要求では、認可サーバの窓口が違うんだな」と知っておきましょう。
![](https://assets.st-note.com/img/1696539648445-0xtRBEgtay.png)
もう一つは、トークンリクエストを送る方法です。次のように、HTTPのボディ部をうまく使っているんです。川崎貴彦さんの記事が分かりやすいのでありがたく×2、引用させていただきます♪。
POST {トークンエンドポイント} HTTP/1.1
Host: {認可サーバー}
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code // 必須
&code={認可コード} // 必須 認可エンドポイントのレスポンスに含まれる値を指定
&redirect_uri={リダイレクトURI} // 認可リクエストに redirect_uri が含まれていれば必須
&code_verifier={ベリファイア} // 認可リクエストに code_challenge が含まれていれば必須
上のように、まずGrant_typeとして「認可コード」を指定して、続いてcodeで認可コードを示すんですね。
これで実際どのようにクラインアントアプリが認可サーバに要求を送っているか、具体的に分かりました!
8.アクセストークンを送る
認可サーバは、トークンエンドポイントで上記のリクエストを受け取ります。確認できたら、アクセストークンを認可コードの代わりに送りかえしてあげます。「これでAPIにアクセスしな!」
![](https://assets.st-note.com/img/1696540159979-8ESi3m2fTX.png)
はい、本日はここまで!無事、クライアントアプリさんは、アクセストークンをゲットできました。その過程を少し詳しめに解説しました。
次回は、アクセストークンを受け取ったあと、どうAPIにサービスリクエストするかを見てみましょうか!
では。
この記事が気に入ったらサポートをしてみませんか?