旧バージョンのドキュメントを参照しています。最新のドキュメントはこちらをご参照ください。

認証リファレンス

アップストリームサービス（APIまたはマイクロサービス）へのトラフィックは、通常、アプリケーションと各種Kong認証プラグインの構成によって制御されます。Kongのサービスエンティティはユーザーのアップストリームサービスを1対1でマッピングするため、ユーザーが選んだサービスで認証プラグインを構成するのが最も単純なシナリオです。

一般的な認証

最も一般的なシナリオでは、認証を義務付け、認証されていないリクエストに対してアクセスを許可しません。このシナリオでは、任意の認証プラグインを使用できます。通常は次のようなスキーム/フローで機能します。

認証プラグインをサービスに適用するか、グローバルに適用します（コンシューマには適用できません）
consumerエンティティを作成する
特定の認証メソッドの認証情報を持つコンシューマを提供します。
リクエストが来るたびに、Kongは提供された認証情報（認証タイプによって異なります）を確認し、検証できない場合はリクエストをブロックするか、コンシューマと認証情報の詳細をヘッダーに追加して、リクエストを転送します。

上記の一般的なフローは、LDAPなどの外部認証を使用する場合など、常に適用されるわけではありません。識別されるコンシューマは存在せず、転送されたヘッダーには認証情報のみが追加されます。

認証方法固有の要素と例は、各プラグインのドキュメントに記載されています。

コンシューマ

コンシューマについて考える最も簡単な方法は、コンシューマをユーザーに1対1でマッピングすることです。しかし、それはKongにとって問題ではありません。コンシューマに関する基本原則は、プラグインをコンシューマに接続して、リクエストの動作をカスタマイズできることです。ですから、あなたはモバイルアプリで、アプリやそのバージョンごとに1人のコンシューマーを定義しているかもしれません。または、プラットフォームごとに、例えばアンドロイドコンシューマ、iOSコンシューマなどのコンシューマがいるかもしれません。

これはKongにとっては不透明な概念のため、彼らは「コンシューマー」と呼ばれ、「ユーザー」とは呼ばれません。

匿名アクセス

Kongには、認証されたアクセスと匿名アクセスの両方を許可するよう特定のサービスを構成する機能があります。この設定を使用して、低い流量制限で匿名ユーザーにアクセスを許可し、認証済みユーザーには高い流量制限でアクセスを許可することができます。

このようなサービスを設定するには、まず選択した認証プラグインを適用してから、新しいコンシューマを作成して匿名ユーザーを表し、匿名アクセスを許可するように認証プラグインを設定します。この例では、example-service という名前のサービスおよび対応するルートが既に設定されていることを前提としています。

例となるサービスとルートを作成する

次のcURLリクエストを発行して、リクエストをエコーするhttpbin.orgを指すexample-serviceを作成します。
```
curl -i -X POST \
  --url http://localhost:8001/services/ \
  --data 'name=example-service' \
  --data 'url=http://httpbin.org/anything'
```
サービスにルートを追加します。
```
curl -i -X POST \
  --url http://localhost:8001/services/example-service/routes \
  --data 'paths[]=/auth-sample'
```
URL http://localhost:8000/auth-sampleは、リクエストされている内容をすべてエコーするようになりました。
サービスに key-auth プラグインを構成

サービスにプラグインを追加するには、次の cURL リクエストを発行します。
```
curl -i -X POST \
  --url http://localhost:8001/services/example-service/plugins/ \
  --data 'name=key-auth'
```
作成したプラグインidを必ずメモしてください。ステップ5で必要になります。
Key Authプラグインが適切に構成されていることを確認します

Key Auth プラグインがサービスに適切に構成されたことを確認するために次のcURLリクエストを発行します。
```
curl -i -X GET \
  --url http://localhost:8000/auth-sample
```
必要なapikeyヘッダーまたはパラメータを指定しておらず、匿名アクセスをまだ有効にしていないため、応答は403 Forbiddenになるはずです。
```
HTTP/1.1 403 Forbidden
...
   
{
  "message": "No API key found in headers or querystring"
}
```
匿名のコンシューマを作成

Kong によってプロキシされるすべてのリクエストは、コンシューマに関連付けられている必要があります。次のリクエストを発行して、anonymous_users（Kong が匿名アクセスをプロキシするときに使用）という名前のコンシューマを作成します。
```
curl -i -X POST \
  --url http://localhost:8001/consumers/ \
  --data "username=anonymous_users"
```
以下のようなレスポンスが表示されます。
```
HTTP/1.1 201 Created
Content-Type: application/json
Connection: keep-alive
   
{
  "username": "anonymous_users",
  "created_at": 1428555626000,
  "id": "bbdf1c48-19dc-4ab7-cae0-ff4f59d87dc9"
}
```
コンシューマ idを必ずメモしてください。次のステップで必要になります。
匿名アクセスを有効にする

次に、key-authプラグインを再構成して以下のリクエストを発行し、匿名のアクセスを許可します（ 以下のサンプルUUIDをステップ2と4のid値に置き換えます ）。
```
curl -i -X PATCH \
  --url http://localhost:8001/plugins/<your-plugin-id id="sl-md0000000"> \
  --data "config.anonymous=<your-consumer-id id="sl-md0000000">"
```
config.anonymous=<your-consumer-id id="sl-md0000000"> パラメータは、このサービスのkey-authプラグインに匿名アクセスを許可し、そのようなアクセスを前の手順で受け取ったコンシューマ idに関連付けるように指示します。この手順では、有効かつ既存のコンシューマidを指定する必要があります。匿名アクセスを設定する時点でコンシューマidの有効性はチェックされておらず、まだ存在しないコンシューマidをプロビジョニングすると、設定が正しく行われません。
匿名アクセスを確認する

次のリクエストを発行して、サービスが匿名アクセスを許可することを確認します。
```
curl -i -X GET \
  --url http://localhost:8000/auth-sample
```
これは、ステップ3で行ったリクエストと同じです。ただし、今回はステップ5で匿名アクセスを有効にしたため、リクエストは成功するはずです。

レスポンス（httpbin が受信したリクエスト）には次の要素が含まれている必要があります。
```
{
  ...
  "headers": {
    ...
    "x-consumer-id": "713c592c-38b8-4f5b-976f-1bd2b8069494",
    "x-consumer-username": "anonymous_users",
    "x-anonymous-consumer": "true",
    ...
  },
  ...
}
```
リクエストは成功したが、匿名であることを示しています。

複数認証

Kongは特定のサービスに対して複数の認証プラグインをサポートしており、異なるクライアントが異なる認証方法を使用して特定のサービスまたはルートにアクセスできるようにします。

複数の認証情報を評価する場合、authプラグインの動作は、論理ANDか、論理ORのいずれかに設定できます。動作のキーは、config.anonymousプロパティです。

config.anonymousが設定されていません
このプロパティが設定されていない場合（空の場合）、認証プラグインは常に認証を実行し、検証されていない場合は40xレスポンスを返します。これにより、複数の認証プラグインが呼び出されたときに論理的なANDが発生します。
config.anonymousが有効なコンシューマIDに設定されています
この場合、認証プラグインはまだ認証されていない場合にのみ認証を実行します。認証が失敗すると40x レスポンスは返されませんが、匿名のコンシューマがコンシューマとして設定されます。これにより、複数の認証プラグインが呼び出され場合、論理的なOR + 「匿名アクセス」が発生します。

注1 : すべての認証プラグインを匿名アクセス用に構成するか、まったく構成しないかのどちらかです。混在している場合の動作は未定義です。

注2 ：AND メソッドを使用する場合、最後に実行されたプラグインは、アップストリームサービスに渡される認証情報を設定するプラグインになります。OR メソッドでは、コンシューマを正常に認証する最初のプラグイン、または構成された匿名コンシューマを設定する最後のプラグインになります。

注3 ：OAuth2プラグインをAND形式で使用する場合、トークンを要求するOAuth2エンドポイントなどでも、他の設定されたauthプラグインによる認証が必要になります。

特定のサービスで複数の認証プラグインがOR形式で有効になっており、匿名アクセスを禁止する場合は、匿名コンシューマで Request Terminationプラグインを構成する必要があります。これを行わないと、不正なリクエストを許可することになります。