OAuth：「引換券」から「トークン」に交換してららおう！認可コードグラント

どうも、こんにちは！前回記事の続きです。ユーザに代わって、アプリが別サービスのAPIを利用できるようにする枠組み「OAuth」についてご紹介しています！

前回は、認可コードグラントの流れ図を途中まで紹介しました。クライアントアプリが認可サーバから「認可コード」をゲットできましたね。ただし、それは「引き換え券」であって、これを使ってAPIのリソースにはアクセスできません…。

今回は、その続き、クライアントアプリが、認可コードを使ってアクセストークンを取得するところまでやりましょう！

では、いってみよう！

認可コードを受け取った後の手順

では、⑦から再スタートです！

７．アクセストークンをリクエストする

引換券…もとい「認可コード」を受け取ったクライアントアプリさんは、その「認可コード」をHTTPリクエストという形で認可サーバに送りかえします。「こんどこそ、アクセストークンをください！」とね。

このトークンリクエストについて、もう少し補足しましょう。

アクセストークンの要求先は、認可サーバの「トークンエンドポイント」となります。他方、認可コードの要求先は、認可サーバの「認可エンドポイント」です。何が違うか？私もよく分かりません（汗）。

とりあえず、「認可コード要求とアクセスコード要求では、認可サーバの窓口が違うんだな」と知っておきましょう。

もう一つは、トークンリクエストを送る方法です。次のように、HTTPのボディ部をうまく使っているんです。川崎貴彦さんの記事が分かりやすいのでありがたく×２、引用させていただきます♪。

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 が含まれていれば必須

@TakahikoKawasaki(川崎 貴彦)のブログから引用転載

上のように、まずGrant_typeとして「認可コード」を指定して、続いてcodeで認可コードを示すんですね。

これで実際どのようにクラインアントアプリが認可サーバに要求を送っているか、具体的に分かりました！

８．アクセストークンを送る

認可サーバは、トークンエンドポイントで上記のリクエストを受け取ります。確認できたら、アクセストークンを認可コードの代わりに送りかえしてあげます。「これでAPIにアクセスしな！」

はい、本日はここまで！無事、クライアントアプリさんは、アクセストークンをゲットできました。その過程を少し詳しめに解説しました。

次回は、アクセストークンを受け取ったあと、どうＡＰＩにサービスリクエストするかを見てみましょうか！

では。