OAuth：全工程がこれで分かった！認可コードグラント
こんにちは！前回記事の続きです。ユーザに代わって、アプリが別サービスのAPIを利用できるようにする枠組み「OAuth」についてご紹介しています！
前回は、認可コードグラントの処理のうち、クライアントアプリが認可コードと引き換えに、アクセストークンを取得する過程をご紹介しました。「認可エンドポイント」ではなく、「トークンエンドポイント」にリクエストを送るのでした。
さて、今回は、クライアントアプリがトークンを取得したあと、APIにリソースへのアクセスを要求する処理についてご紹介します。
トークンを取得してしまえば、「認可コードグラント」と他の認可フロー（インプリシットなど）で大きな違いはないかもしれません。が、どんなやりとりがあるのか気になりますね！
いってみましょう！
いよいよリソースサーバへAPIアクセス
では、アクセストークンをクライアントアプリが取得したあとの流れについてお話しします。
絵にすると次のとおりです。アプリがリソース提供をお願いし、リソースサーバ（認可サーバではないです）がリソースを提供します。
シンプルですね。ここでは、「アプリがリソースにアクセスする際に、どのようにトークンを送っているか」に着目することにしましょう！
９．リソースにアクセス
クライアントアプリさんは、引換券もとい「認可コード」を認可サーバに返すことによって、無事「アクセストークン」を取得しました。
続いて、これをリソースサーバのAPIに渡します。でも、どうやって？
実は、HTTPリクエストのヘッダーの一つとして、「Authorization」ヘッダーを加えて、これを使って送ります。
具体的には、ヘッダーは次のようになります。
Authorization: Bearer <アクセストークン>
HTTP認証で使われるAuthorizationヘッダー
このAuthorizationヘッダーは、HTTPのシリーズ記事でも登場しました！簡単に振り返ります。
例えば、Basic認証では、
Authorization: Basic IDとパスワードをコロンでつなげてBase64でエンコードした文字列
のように記述するのでした。
また、Digest認証では、
Authorization: Digest username="hoge", realm="Digest", 以下省略
のように記述するのでした。
このように、Authorizationヘッダーは、HTTPの仕様を使ってクライアントがサーバに「認証」してもらうために送るのでした（OAuthでは「認可」ですけれども。英単語の意味としてはOAuthの「認可」の方が正しいですね…）。
なお、「Authorization:」の後ろで指定するBasic、Digest、Bearerは「スキーム」と呼ばれます。
Bearerトークンとは何か？
また、アクセストークンがどのようにできているか気になるのではないでしょうか？
実は、「token68」という形式で作られています。68種の文字と”=”、あわせて69種の文字が使用可能です（このあたり、MIMEで使われるBase64と似てますね～）。
token68を使った文字列は例えば次のよう人なります。
aBc123.-_~+/=
現実のトークンは、もっと長く、もっと不規則で、もっと複雑なものです。
Bearerって何よ？
最後に気になるのがBearerですね。Bearerは、「所有している人」くらいにとらえてよいと思います。例えば、英語で「パスポートを持っている人」であれば、Passport bearerなんて言ったりします。
OAuthの文脈では、「アクセストークンを持っている人」ということになりましょいう。
「このトークンの所有者で認可済みだから、APIにアクセスさせてよ！」という趣旨ですね～。
以上がBearerトークンのお話でした。
10.リソースを提供する
最後に、リソースサーバが、アクセストークンを検証して、APIを通じてリソースをクライアントアプリに提供します。
これで認可コードグラントの全工程が完結です！シーケンス図全体を示して終わりにします！（最初にこれを示したかったのですけれども！）。
次回からOpenID Connectを紹介したいと思います！
この記事が気に入ったらサポートをしてみませんか？