リソース オーナー パスワード(または「パスワード」)の権限付与タイプは、主にアプリの信頼性が高い場合に使用されます。この構成では、ユーザーは自分のリソース サーバーの認証情報(ユーザー名とパスワード)をクライアント アプリに提供し、クライアント アプリは Apigee Edge へのアクセス トークン リクエストでそれを送信します。ID サーバーがその認証情報を検証して有効である場合、Edge はアクセス トークンの作成に進み、アクセス トークンをアプリに返します。
このトピックについて
このトピックでは、OAuth 2.0 のリソース オーナー パスワードの権限付与タイプのフローについて、全般的な説明と概要を示し、Apigee Edge でこのフローを実装する方法を説明します。
有用な例
- アクセス トークンのリクエスト: パスワード付与タイプ: トークン リクエストの構成方法、パスワード付与タイプの OAuthV2 ポリシーの構成方法、および Edge でのポリシーのエンドポイントの構成方法を示します。
- oauth-validate-key-secret: Edge にデプロイして試すことができる GitHub のサンプル プロキシ。パスワードの権限付与タイプを使用するエンドツーエンドの例となります。クライアント アプリの認証情報(キー / シークレット)を認証した後にユーザーの認証情報を ID プロバイダに送信する、というベスト プラクティスの実例が示されています。
動画
動画: パスワード付与タイプ実装時にこの動画をご覧ください。
使用例
この権限付与タイプは、ユーザーが自分のリソース サーバーの認証情報をアプリに提供する必要があるため、信頼性や権限が高いアプリで使用します。通常、そのようなアプリには、ユーザーが自分の認証情報を入力するログイン画面があります。
フロー図
次のフロー図は、Apigee Edge が認可サーバーとして機能する、リソース オーナー パスワードの権限付与タイプのフローを示しています。
ヒント: この図を拡大するには、図を右クリックして新しいタブで開くか、保存して画像ビューアで開きます。
パスワードの権限付与タイプのフローでのステップ
Apigee Edge が認可サーバーの役割を果たす、パスワードの権限付与タイプを実装するために必要なステップの概要を以下に示します。
前提条件: クライアント ID とクライアント シークレット キーを取得するには、クライアント アプリを Apigee Edge に登録する必要があります。詳しくは、クライアント アプリの登録をご覧ください。
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 認証ヘッダー内でエンコードされます。必要な Basic 認証ヘッダーの詳細など、この API 呼び出しの詳細については、アクセス トークンと認可コードのリクエストのパスワード付与のセクションをご覧ください。
3. Edge がクライアント アプリを検証する
ユーザーの認証情報とパスワードを ID プロバイダに送信する前に、Edge はリクエストを作成したクライアント アプリが有効であり、信頼済みのアプリであることを識別する必要があります。そのための 1 つの方法は API 呼び出しで API キー認証を使用することです。場合によっては、クライアント キーとシークレットの両方を検証することもできます。GitHub の api-platform-samples リポジトリにこのもう 1 つの手法を表すサンプル プロキシが掲載されています。
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