HTTP認証＠認証¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. HTTP認証とは¶
HTTPプロトコルの中で認証を行う認証スキームのこと。
リクエストのauthorizationヘッダーとレスポンスのWWW-Authenticateヘッダーで認証スキームを指定する。
認証スキームの種類には、『Basic認証』、『Digest認証』、『Bearer認証』などがある。
認証情報の一時的な保存は、ブラウザのWebStoregeで行うため、認証解除 (ログアウト) をサーバー側で完全に制御できない。
02. Basic認証¶
Basic認証とは¶
認証時に、平文のIDとパスワードを使用する認証スキームのこと。
Basic認証の仕組み¶
| 役割 | 説明 |
|---|---|
| クライアント | リクエスト送信元のアプリケーションのこと。文脈によっては、ブラウザがクライアントである場合とそうでない場合 (例：OAuth) がある。 |
| ユーザー | クライアントを使用している人物のこと。 |
| サーバー | クライアントからリクエストを受信し、レスポンスを返信するアプリケーションのこと。 |
(1)-
最初、クライアントは、認証後にリクエストを送信できるWebページのリクエストをサーバーに送信する。
GET https://example.com/foo-form
(2)-
サーバーは、これ拒否し、
401ステータスで認証領域を設定し、レスポンスを返信する。これにより、認証領域の値をユーザーに示して、ユーザー名とパスワードの入力を求められる。
ユーザーに表示するための認証領域には、任意の値を持たせられ、サイト名が設定されることが多い。
401 Unauthorized
---
WWW-Authenticate: Basic realm="<認証領域>", charaset="UTF-8"
(3)-
『
<ユーザー名>:<パスワード>』をbase64方式でエンコードした値をauthorizationヘッダーに割り当て、リクエストを送信する。
POST https://example.com/foo-form
---
authorization: Basic bG9naW46cGFzc3dvcmQ=
(4)-
サーバーは、ユーザー名とパスワードを照合し、合致していれば、認証後のWebページを返信する。
また、認証情報をブラウザのWebストレージに保存する。
200 OK
---
WWW-Authenticate: Basic realm=""
(5)-
認証の解除時は、誤った認証情報をブラウザに意図的に送信させて認証を失敗する。
POST https://example.com/foo-form/logout
---
authorization: Basic <誤った認証情報>
(6)-
サーバーは、
401ステータスでレスポンスを返信し、認証が解除される。
401 Unauthorized
---
WWW-Authenticate: Basic realm="<認証領域>", charaset="UTF-8"
03. Digest認証¶
Digest認証とは¶
認証時に、ハッシュ化されたIDとパスワードを使用する認証スキームのこと。
Digest認証の仕組み¶
200 OK
---
WWW-Authenticate: Basic realm="<認証領域>", charaset="UTF-8"
POST https://example.com/foo-form
---
authorization: Digest realm="<認証領域>" nonce="<サーバー側が作成した任意の文字列>" algorithm="<ハッシュ関数名>" qoq="auth"
04. Bearer認証¶
Bearer認証とは¶
認証時に、Bearerトークンを使用する認証スキームのこと。
Bearerトークン (署名なしトークン) とは¶
単なる文字列で定義されたアクセストークン。
Bearer認証にて、トークンとして使用する。
署名なしトークンとも呼ばれ、実際に認証済みの本人か否かを判定する機能は無く、トークンを持っていればそれを本人として認可する。
そのため、トークン文字列が流出してしまわないよう、厳重に管理する必要がある。
Bearer認証の仕組み¶
(1)-
指定されたエンドポイントに対して、
POSTリクエストを送信する。この時、
Content-Typeヘッダーをapplication/x-www-form-urlencodedとする。必要なボディパラメーターはAPIの提供元によって異なる。クライアントID、付与タイプ、などが必要なことが多い。
POST https://example.com/foo
---
Content-Type: application/x-www-form-urlencoded
---
# ボディ
client_id=*****&grant_type=client_credentials&scope=messaging:push
(2)-
レスポンスボディにBearerトークンを含むレスポンスが返信される。
他に、有効期限、権限のスコープ、指定できる認証スキーマ、などが提供されることが多い。
200 OK
---
X-Amzn-RequestId: d917ceac-2245-11e2-a270-0bc161cb589d
Content-Type: application/json
---
{
"access_token": "*****",
"expires_in": 3600,
"scope": "messaging:push",
"token_type": "Bearer",
}
(3)-
発行されたBearerトークンを指定された認証スキーマで
Authorizationヘッダーに割り当て、リクエストを送信する。ここでは詳しく言及しないが、BearerトークンをForm認証のように
Cookieヘッダーに割り当てることもある。
POST https://example.com/foo
---
authorization: Bearer <Bearerトークン>
(4)-
サーバーは、Bearerトークンを照合し、合致していれば、認証後のWebページを返信する。
無効なBearerトークンをブラックリストとしてRedis/DBで管理しておく。
DBでブラックリストを管理すると、リクエストの度にDBアクセス処理が実行されることなってしまうため、Redisでこれを管理した方が良い。
200 OK
---
WWW-Authenticate: Bearer realm=""
(5)-
認証の解除時は、Redis/DBでBearerトークンの状態を無効化する。
またサーバーは、
401ステータスでレスポンスを返信し、認証が解除される。
401 Unauthorized
---
WWW-Authenticate: Basic realm="<認証領域>", charaset="UTF-8"
正常系/異常系レスポンス¶
成功の場合は、realm属性を空にしたレスポンスを返信する。
200 OK
---
WWW-Authenticate: Bearer realm=""
失敗の場合は、error属性にエラメッセージを割り当てたレスポンスを返信する。
400 Bad Request
---
WWW-Authenticate: Bearer error="invalid_request"
401 Unauthorized
---
WWW-Authenticate: Bearer realm="token_required"
403 Forbidden
---
WWW-Authenticate: Bearer error="insufficient_scope"
Authorizationヘッダーのトークンのクライアント保持¶
不便ではあるが、AuthorizationヘッダーはCookieヘッダーとは異なり、ローカルマシンに保存できない。
その代わり、ブラウザの設定によって、ブラウザのWebストレージでも保持できる。
Chromeでは、ローカルストレージあるいはセッションストレージに保持される。
ローカルストレージはセッションストレージと比べて保管期間が長いため、XSSの危険性がより高い。
これらの場所の確認方法については、以下のリンクを参考にせよ