APIの認証 トークンとAPIキー

このレッスンで学ぶこと

APIの認証は、Cookieを持たない相手がAuthorizationヘッダーにトークンやAPIキーを載せて名乗る仕組みです。この回は、その名乗りの形と、よく使われるJWTの性質を扱います。

読み終えるころには、Networkに出たAuthorizationの値を自分の手で分解して、何が確かめられて何が確かめられないかを言えるようになります。

Cookieのセッションと、トークンの違い

前回、プロキシから直接APIを呼びました。このとき、ブラウザが自動で付けていたCookieはありません。だからAPIを呼ぶ相手は、リクエストのたびに自分でヘッダーに名乗りを付けます。

GET /api/orders/1043
Authorization: Bearer eyJhbGciOiJ...

AuthorizationヘッダーにBearerトークンを載せます。ブラウザのセッションが「発行済みのCookieを自動で送る」のに対し、こちらは呼ぶ側が明示的に付ける点が違います。モバイルアプリや他のサービス、スクリプトからの呼び出しはこの形です。

APIキーの置き場所と期限

サービス単位の長期の合言葉として、APIキーもよく使われます。これもヘッダーに載せて送ります。注意すべき点は置き場所と期限の二つです。キーをフロントエンドのJavaScriptに埋め込むと、配信されるバンドルの中に丸見えで残ります。利用者のブラウザに届くコードに秘密を置くと、それはもう秘密ではありません。 有効期限が無いキーは、一度漏れると被害が続くので、期限を切って入れ替えられるようにします。

JWTの中身は誰でも読める

Bearerトークンとしてよく使われるJWTは、ドットで区切られた三つの部分でできています。前の二つ、ヘッダーとペイロードは、Base64URLで表しただけです。暗号化ではないので、ドットで割ってデコードすれば誰でも中身を読めます。

eyJhbGci.eyJyb2xlIjoi.SflKxwRJ
ヘッダー   ペイロード      署名

デコードするとroleや有効期限といった値が平文で出てきます。ここを取り違えると危ないので、はっきりさせます。JWTの署名は、中身が途中で書き換えられていないことを確かめる仕組みです。中身を秘密にする仕組みではありません。だからパスワードや他人に見せたくない値をペイロードに入れてはいけません。

どう直すか

トークンには短めの有効期限を付け、切れたら取り直す形にします。機密の値はペイロードに入れず、サーバー側に持ちます。APIキーは環境変数やサーバー内に置き、配信されるバンドルには含めません。

手を動かすときは、練習用の環境で、Networkに出たAuthorizationヘッダーの値をコピーし、ドットで区切った二つ目をBase64URLとしてデコードして、何が読めるかを確かめてください。

まとめ