パスワードの権限付与タイプの実装

リソース オーナー パスワード(または「パスワード」)の権限付与タイプは、主にアプリの信頼性が高い場合に使用されます。この構成では、ユーザーは自分のリソース サーバーの認証情報(ユーザー名とパスワード)をクライアント アプリに提供し、クライアント アプリは Apigee Edge へのアクセス トークン リクエストでそれを送信します。ID サーバーがその認証情報を検証して有効である場合、Edge はアクセス トークンの作成に進み、アクセス トークンをアプリに返します。

このトピックについて

このトピックでは、OAuth 2.0 のリソース オーナー パスワードの権限付与タイプのフローについて、全般的な説明と概要を示し、Apigee Edge でこのフローを実装する方法を説明します。

有用な例

  • アクセス トークンのリクエスト: パスワードの権限付与タイプ: トークン リクエストを形成する方法、パスワードの権限付与タイプ用の OAuthV2 ポリシーを構成する方法、そのポリシー用のエンドポイントを Edge で構成する方法が示されています。
  • oauth-validate-key-secret: GitHub で提供され、Edge にデプロイして試すことができるサンプル プロキシ。パスワードの権限付与タイプを使用するエンドツーエンドの例となります。クライアント アプリの認証情報(キー / シークレット)を認証した後にユーザーの認証情報を ID プロバイダに送信する、というベスト プラクティスの実例が示されています。

動画

動画: パスワードの権限付与タイプの実装に関するこちらの動画をご覧ください。

使用例

この権限付与タイプは、ユーザーが自分のリソース サーバーの認証情報をアプリに提供する必要があるため、信頼性や権限が高いアプリで使用します。通常、そのようなアプリには、ユーザーが自分の認証情報を入力するログイン画面があります。

フロー図

次のフロー図は、Apigee Edge が認可サーバーとして機能する、リソース オーナー パスワードの権限付与タイプのフローを示しています。

ヒント: この図の拡大版を見るには、図を右クリックして新しいタブで開くか、図を保存して画像ビューアで開きます。

パスワードの権限付与タイプのフローでのステップ

Apigee Edge が認可サーバーの役割を果たす、パスワードの権限付与タイプを実装するために必要なステップの概要を以下に示します。

前提条件: クライアント アプリを Apigee Edge に登録し、クライアント ID とクライアント シークレット キーを取得している必要があります。詳しくはクライアント アプリの登録をご覧ください。

1. ユーザーがフローを開始して認証情報を入力する

アプリがユーザーの保護されたリソースにアクセスする必要がある場合(たとえば、ユーザーがアプリ内のボタンをクリックした場合)、ユーザーはログイン フォームにリダイレクトされます。

2. アプリが Apigee Edge からのアクセス トークンをリクエストする

アプリは、ユーザーの認証情報が含まれているアクセス トークン リクエストを Apigee Edge の GenerateAccessToken エンドポイントに送信します。

サンプル POST リクエストを次に示します。この例には、この権限付与タイプの必須パラメータが含まれています。

    $ curl -i \
      -X POST \
      -H 'Content-Type: application/x-www-form-urlencoded' \
      -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
      -d 'grant_type=password&username=the-user-name&password=the-users-password' \
      https://docs-test.apigee.net/oauth/token
    

上記のコマンドの代わりに、次のように curl の -u オプションを使用して、Base64 エンコードの Basic 認証ヘッダーを作成することもできます。

    $ curl -i \
      -X POST \
      -H 'Content-Type: application/x-www-form-urlencoded' \
      -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
      -d 'grant_type=password&username=the-user-name&password=the-users-password' \
      https://docs-test.apigee.net/oauth/token
    

(これらのコマンドはそれぞれ全体を 1 行で入力する必要があります)

ユーザー認証情報はフォーム パラメータに含まれる一方、クライアント認証情報は HTTP Basic 認証ヘッダー内でエンコードされます。この API 呼び出しの詳細な説明については(必須の Basic 認証ヘッダーも含めて)、アクセス トークンと認可コードのリクエストのパスワードの権限付与のセクションをご覧ください。

3. Edge がクライアント アプリを検証する

ユーザーの認証情報とパスワードを ID プロバイダに送信する前に、Edge はリクエストを作成したクライアント アプリが有効であり、信頼済みのアプリであることを識別する必要があります。そのための 1 つの方法は API 呼び出しで API キー認証を使用することです。場合によっては、クライアント キーとシークレットの両方を検証することもできます。この代替手法を示すサンプル プロキシが、GitHub の api-platform-samples リポジトリにあります。

4. Edge がログイン認証情報を処理する

クライアント アプリが検証されたら、Service Callout または JavaScript ポリシーを使用して、ID サービスを呼び出してユーザーの認証情報を送信できます。たとえば、LDAP サービスや、認証情報の検証に使用する任意のサービスを使用できます。これらのポリシーについて詳しくは、Extract Variables ポリシーJavaScript ポリシーをご覧ください。

ID サービスが認証情報を検証してステータス コード 200 のレスポンスを返した場合、Edge はリクエストの処理を続行します。それ以外のステータス コードのレスポンスの場合、Edge は処理を停止してクライアント アプリにエラーを返します。

5. OAuthV2 ポリシーが実行される

認証情報が有効である場合、次の処理ステップは、パスワードの権限付与タイプに対して構成されている OAuthV2 ポリシーを実行することです。以下に例を示します。<UserName> と <PassWord> 要素は必須で、これらは ExtractVariables ポリシーにより保存されたフロー変数から取得できます。このポリシーについて詳しくは OAuthV2 ポリシーをご覧ください。

    <OAuthV2 name="GetAccessToken">
      <Operation>GenerateAccessToken</Operation>
      <ExpiresIn>360000000</ExpiresIn>
      <SupportedGrantTypes>
         <GrantType>password</GrantType>
      </SupportedGrantTypes>
      <GrantType>request.queryparam.grant_type</GrantType>
      <UserName>login</UserName>
      <PassWord>password</PassWord>
      <GenerateResponse/>
    </OAuthV2>
    

このポリシーが成功すると、アクセス トークンが含まれたレスポンスが生成され、クライアントに返されます。そのレスポンスは JSON 形式です。次に例を示します。access_token は複数ある要素の中の 1 つです。

    {
        "issued_at": "1420258685042",
        "scope": "READ",
        "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
        "refresh_token_issued_at": "1420258685042",
        "status": "approved",
        "refresh_token_status": "approved",
        "api_product_list": "[PremiumWeatherAPI]",
        "expires_in": "1799",
        "developer.email": "tesla@weathersample.com",
        "organization_id": "0",
        "token_type": "BearerToken",
        "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
        "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
        "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
        "organization_name": "docs",
        "refresh_token_expires_in": "0",
        "refresh_count": "0"
    }
    

6. 保護された API をクライアントが呼び出す

これで、クライアントが、有効なアクセスコードを使用して、保護された API を呼び出すことができるようになりました。このシナリオでは、Apigee Edge(プロキシ)に対してリクエストが行われ、Edge はターゲット リソース サーバーに API 呼び出しを渡す前にアクセス トークンを検証する責任を担います。アクセス トークンは Authorization ヘッダーで渡されます。例:

    $ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
    " http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282