カスタム JWT 認証の構成 (Okta、Auth0)

データ API ビルダーは、カスタム認証プロバイダーを介してサードパーティの ID プロバイダーをサポートします。組織で Okta、Auth0、または別の OAuth 2.0/OpenID Connect 準拠 ID プロバイダーを使用している場合は、この方法を使用します。

認証フロー

カスタム ID プロバイダーでは、クライアントアプリがユーザー認証を処理し、アクセストークンを Data API ビルダーに送信します。

サードパーティの ID プロバイダーを使用したカスタム JWT 認証フローの図。

Phase	何が起こるか
ユーザー認証	ユーザーは ID プロバイダー (Okta、Auth0 など) を介してサインインします。
トークンの取得	クライアントアプリが IdP からアクセストークンを受け取る
API 呼び出し	クライアントがトークンを `Authorization` ヘッダーの DAB に送信する
Validation	DAB は JWT (発行者、対象ユーザー、署名) を検証します
認可	DAB がロールを抽出し、アクセス許可を評価する

[前提条件]

あなたの ID プロバイダー (Okta、Auth0 など) と関連付けられたアカウント
ID プロバイダーに登録されているアプリケーション
Data API Builder CLI がインストールされている (インストールガイド)
少なくとも 1 つのエンティティを持つ既存のdab-config.json

クイックリファレンス

Setting	価値
プロバイダー	`Custom`
検証に必要	`iss`、 `aud`、 `exp`、有効な署名
承認に必要	`roles` 選択したロールを含む要求
トークンヘッダー	`Authorization: Bearer <token>`
ロールクレームタイプ	`roles` (固定、構成できません)
ロールの選択ヘッダー	`X-MS-API-ROLE`

手順 1: ID プロバイダーを構成する

正確な手順は、プロバイダーによって異なります。必要なキー値を次に示します。

収集する値

価値	参照先	使用目的
発行者の URL	プロバイダーのドキュメントまたは OAuth メタデータエンドポイント	DAB `jwt.issuer` (JWT 認証機関として使用)
オーディエンス	アプリケーションのクライアント ID またはカスタム API 識別子	DAB `jwt.audience`

注

DAB は、構成された jwt.issuer を JWT 機関として使用 します。署名キーは、標準の OpenID Connect メタデータ (通常は <issuer>/.well-known/openid-configuration) を介して自動的に検出されます。

Okta の例

Okta 管理コンソールにサインインします。
Applications>Applications に移動します。
アプリケーションを作成または選択します。
クライアント ID をメモします (対象ユーザーとして使用します)。
通常、発行者は https://<your-domain>.okta.com。

Auth0 の例

Auth0 ダッシュボードにサインインします。
アプリケーション>API に移動します。
API を作成または選択します。
識別子をメモします (対象ユーザーとして使用します)。
発行者は https://<your-tenant>.auth0.com/ です。

Important

データ API ビルダーは、ロールベースの承認に固定要求の種類の roles を使用します。この値は構成できません。 ID プロバイダーが別の要求 ( groups や permissionsなど) でロールを出力する場合は、 roles 要求も出力するようにプロバイダーを構成するか、ログイン後アクションを使用して値を roles 要求にコピーする必要があります。

手順 2: データ API ビルダーを構成する

認証プロバイダーを Custom に設定し、JWT 設定を構成します。

# Set the authentication provider
dab configure \
  --runtime.host.authentication.provider Custom

# Set the expected audience
dab configure \
  --runtime.host.authentication.jwt.audience "<your-api-identifier>"

# Set the expected issuer
dab configure \
  --runtime.host.authentication.jwt.issuer "https://<your-issuer>/"

REM Set the authentication provider
dab configure ^
  --runtime.host.authentication.provider Custom

REM Set the expected audience
dab configure ^
  --runtime.host.authentication.jwt.audience "<your-api-identifier>"

REM Set the expected issuer
dab configure ^
  --runtime.host.authentication.jwt.issuer "https://<your-issuer>/"

結果の構成

{
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Custom",
        "jwt": {
          "audience": "<your-api-identifier>",
          "issuer": "https://<your-issuer>/"
        }
      }
    }
  }
}

手順 3: エンティティのアクセス許可を構成する

ID プロバイダーが割り当てるロールのアクセス許可を定義します。

CLI

バッシュ
コマンドプロンプト

# Allow authenticated users to read
dab update Book \
  --permissions "authenticated:read"

# Allow users with 'admin' role full access
dab update Book \
  --permissions "admin:*"

REM Allow authenticated users to read
dab update Book ^
  --permissions "authenticated:read"

REM Allow users with 'admin' role full access
dab update Book ^
  --permissions "admin:*"

結果の構成

{
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "authenticated",
          "actions": ["read"]
        },
        {
          "role": "admin",
          "actions": ["*"]
        }
      ]
    }
  }
}

手順 4: ID プロバイダーでロールを構成する

DAB は、 roles 要求のロールを想定しています。この要求を含むように ID プロバイダーを構成します。

Okta: ロールとしてグループを追加する

Okta 管理コンソールで、 Security>API に移動します。
承認サーバーを選択します。
[ 要求 ] タブに移動します。
要求を追加します。
- 名前: roles
- トークンの種類に含める: アクセストークン
- 値の種類: グループ
- フィルター: 含めるグループを選択します

Auth0: アクションを使用してロールを追加する

Auth0 ダッシュボードで、[>Library] に移動します。
新しいアクション (ログイン後トリガー) を作成します。
ロールを含めるコードを追加します。

exports.onExecutePostLogin = async (event, api) => {
  const roles = event.authorization?.roles || [];
  if (roles.length > 0) {
    api.accessToken.setCustomClaim('roles', roles);
  }
};

アクションをデプロイし、ログインフローに追加します。

ヒント

Okta を使用した JWT 要求の構成に関する詳細なガイダンスについては、「 Okta の SDK を使用した高度な JWT 要求の実装」を参照してください。

手順 5: 構成をテストする

データ API ビルダーを起動します。
```
dab start
```
ID プロバイダーからトークンを取得します。プロバイダーの SDK または Postman などのツールを使用します。
jwt.io でトークンを調べて、次のことを確認します。
- aud要求は、構成された対象ユーザーと一致します
- issクレームは、構成された発行者と一致します
- roles要求には、予期される値が含まれています

API を呼び出します。

curl -X GET "http://localhost:5000/api/Book" \
  -H "Authorization: Bearer <your-token>"

カスタムロールを使用するには、 X-MS-API-ROLE ヘッダーを含めます。

curl -X GET "http://localhost:5000/api/Book" \
  -H "Authorization: Bearer <your-token>" \
  -H "X-MS-API-ROLE: admin"

JWT 検証の詳細

データ API ビルダーは、JWT の次の側面を検証します。

確認	Description
署名	構成された `jwt.issuer` 機関 (OpenID Connect メタデータ/JWKS) を介して検出された署名キーを使用して検証されます
発行者	`jwt.issuer`構成と完全に一致する必要があります
オーディエンス	`jwt.audience`構成と完全に一致する必要があります
[有効期限]	トークンの有効期限が切れていないこと（`exp` クレーム）
前にありません	トークンは有効である必要があります（クレーム`nbf` が存在する場合）

トラブルシューティング

症状	考えられる原因	解決策
`401 Unauthorized`	発行者の不一致	`iss`要求が正確に一致しているかを確認する（末尾のスラッシュを含む）
`401 Unauthorized`	オーディエンスの不一致	`aud`要求が構成された値と一致するかどうかを確認する
`401 Unauthorized`	トークンの有効期限が切れています	新しいトークンを取得する
`401 Unauthorized`	メタデータを使用できない	DAB が到達できることを確認する `<issuer>/.well-known/openid-configuration`
`403 Forbidden`	トークン内にないロール	IdP 構成にロールを追加する
`403 Forbidden`	ロールのクレームが不足しています	`roles`要求を含むように IdP を構成する
`403 Forbidden`	要求名が正しくありません	DAB は要求の種類の `roles` を使用します (固定、構成できません)

Important

DAB では現在、すべてのロールチェックに要求の種類 roles が使用されています。この値はハードコーディングされており、 groups、 permissions、またはその他の要求名に変更することはできません。 rolesという名前のクレームでロールを出力するようにIDプロバイダーを設定してください。

一般的な発行元の形式

プロバイダー	発行者の形式
Okta	`https://<domain>.okta.com` または `https://<domain>.okta.com/oauth2/default`
Auth0	`https://<tenant>.auth0.com/` (末尾のスラッシュに注意してください)
Azure AD B2C	`https://<tenant>.b2clogin.com/<tenant-id>/v2.0/`
Keycloak	`https://<host>/realms/<realm>`

完全な構成例

Okta の構成

{
  "$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  },
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Custom",
        "jwt": {
          "audience": "0oa1234567890abcdef",
          "issuer": "https://dev-12345.okta.com"
        }
      }
    }
  },
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "authenticated",
          "actions": ["read"]
        },
        {
          "role": "editor",
          "actions": ["create", "read", "update"]
        }
      ]
    }
  }
}

Auth0 の構成

{
  "$schema": "https://github.com/Azure/data-api-builder/releases/latest/download/dab.draft.schema.json",
  "data-source": {
    "database-type": "mssql",
    "connection-string": "@env('SQL_CONNECTION_STRING')"
  },
  "runtime": {
    "host": {
      "authentication": {
        "provider": "Custom",
        "jwt": {
          "audience": "https://my-api.example.com",
          "issuer": "https://my-tenant.auth0.com/"
        }
      }
    }
  },
  "entities": {
    "Book": {
      "source": "dbo.Books",
      "permissions": [
        {
          "role": "authenticated",
          "actions": ["read"]
        },
        {
          "role": "admin",
          "actions": ["*"]
        }
      ]
    }
  }
}

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-01-23

次の方法で共有

カスタム JWT 認証の構成 (Okta、Auth0)

認証フロー

[前提条件]

クイック リファレンス

手順 1: ID プロバイダーを構成する

収集する値

Okta の例

Auth0 の例

手順 2: データ API ビルダーを構成する

CLI

結果の構成

手順 3: エンティティのアクセス許可を構成する

CLI

結果の構成

手順 4: ID プロバイダーでロールを構成する

Okta: ロールとしてグループを追加する

Auth0: アクションを使用してロールを追加する

手順 5: 構成をテストする

JWT 検証の詳細

トラブルシューティング

一般的な発行元の形式

完全な構成例

Okta の構成

Auth0 の構成

関連コンテンツ

フィードバック

その他のリソース

クイックリファレンス