OAuth：「認可コード」をまずはゲット！認可コードグラント

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

前回は、認可コードグラントの流れの途中までご紹介しました。シーケンス図に登場する人物を確認したのち、クライアントによる認可リクエスト、認可サーバによる認証要求までやりました。

さて、今回は認可コードグラントの流れの続きです。先を急ぎましょう！

レッツゴー！

認可コードグラント、続きの手順

前回記事で、認可サーバがユーザにブラウザを通じて認証を要求するステップまでご紹介しました。その続きですね。

３．ユーザが認証情報を入力・送信

ブラウザに認証要求が表示されるので、ユーザは、（リソースサーバ側のサービスの）IDとパスワードなどを入力して送信します。その後、認可サーバで認証されます。リソース側にログインできました。

ここでポイントになるのは、クライアントアプリは、このクレデンシャル（ユーザIDとパスワード）を知ることはないことです。クライアントアプリ側にそれらを渡してはリスクが増えるのでしたね。シーケンス図では分かりにくいですが、アプリはこの過程ではスルーされています。

４．アクセス権限移譲の確認

認証が完了したら、認可サーバは、ブラウザを通じてユーザにアクセス権限移譲の可否を確認します。

メッセージの内容はだいたいこんな感じです。

「Aサービスがアクセスを要求しています。許可しますか？」
「Aサービスにアカウントへのアクセスを許可しますか？」

どこかで見たことあるメッセージですよね。

５．アクセス権限移譲の同意

ユーザは、クライアントアプリにアクセス権限を持たせたいので、表示される注意事項（どんな権限が渡されるのかなど）をよく読んでから「はい」を押します。

でも、よく考えずに「はい」を押しているのは私だけではないですよね…。

６．認可コードの送信

ユーザから権限移譲の承諾が得られたので、認可サーバはブラウザからリダイレクトして、認可コードをクライアントアプリへ送ります。

クライアントアプリは、喜びます。「よかった！なんかゲットしたぞ！」と。そして気づきます。「あれ、これは引換券か…。」

はい、本日は、ここまで。今回はクライアントアプリが「認可コード」をゲットするところまでご紹介しました。しかし、このままではまだAPIにアクセスしてリソースを使わせてもらえません。

次回は、認可コードグラントの続きからやりましょう！

では。