クライアント・アプリケーションでの OAuth 2.0 ベース認証の使用

Open Authorization (OAuth) 2.0 では、リソース所有者が保護リソースへのアクセス権限を付与できるいくつかの方法について説明しています。 IBM® Cloud Pak for Business Automation as a Serviceは、クラウド環境へのクライアントアプリケーションのアクセス認証において、リソースオーナーパスワード認証(ROPC)の付与タイプのみをサポートしています。

注: OAuth 2.0 ベースの認証は、クラウドサブスクリプションではデフォルトでは有効になっていません。 ご希望の方は、 IBM サポートポータルからリクエストをお送りください。 外部リンクは新しいウィンドウまたはタブで開きます.

ROPC 付与タイプ

OAuth 2.0 の用語では、 Cloud Pak for Business Automation as a Service クライアント・アプリケーションは機密クライアントです。 ROPC 付与タイプの場合、クライアント資格情報セット (クライアント ID とクライアント秘密鍵で構成される) とリソース所有者のユーザー名とパスワードが必要です。 クライアント資格情報を取得するには、Credentials API を使用して資格情報を生成します。 ユーザー名とパスワードの場合、アカウント管理者としてクラウド・ポータルにログインし、一連のサービス資格情報を生成してから、クライアント・アプリケーションが必要とする権限を割り当てます。 これらの権限が、クラウド環境への OAuth 2.0 トークン・ベースのアクセスを制御するために使用されます。

OAuth と ROPC のグラントタイプの詳細については、 OAuth 2.0 Authorization Framework を参照してください。 外部リンクは新しいウィンドウまたはタブで開きます. 詳細については、 Credentials API については、 「例: OAuth 2.0 ベースの認証の資格情報 REST API」を参照してください。サービス資格情報の取得については、 「サービス アカウントの作成と管理」を参照してください。

OAuth 2.0 クライアント資格情報の管理

OAuth 2.0 クライアントは、呼び出し側クライアント・コンテキストを識別するためのクライアント資格情報を提供する必要があります。 必要な資格情報セットの数を判別します。 例えば、すべての OAuth 2.0 クライアントに対して 1 セットを使用することも、クライアントごとに個別の資格情報セットを持つこともできます。

クライアント・アプリケーションで OAuth 2.0 認証を使用するには、アプリケーションに以下の対話を含める必要があります。
重要: 以下の呼び出しは、応答の一部として PD-S-SESSION-ID Cookie および PD-ID Cookie の Set-Cookie コマンドを返す場合があります。 後続の呼び出しでそれらの Cookie を使用しないでください。
  1. OAuth 2.0 アクセス・トークンを取得します。
    OAuth 2.0 /token エンドポイントを使用して、クライアント資格情報 (クライアント ID とクライアント秘密鍵) およびサービス資格情報 (ユーザー名とパスワード) を含むアクセス・トークンを取得します。 例:
    curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
    -d grant_type=password -d client_id=<clientId> -d client_secret=<clientSecret>
    -d username=<serviceCredId> -d password=<svcCredSecret>
    https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
    
    この呼び出しは、後続のクラウド操作 API 呼び出しで使用されるアクセス・トークン、アクセス・トークンをリフレッシュするためのリフレッシュ・トークン、およびアクセス・トークンの有効期間を返します。 アクセス・トークンは通常、分単位または時間単位で有効であるのに対し、リフレッシュ・トークンは日単位で有効であることに注意してください。 スコーピングはサポートされません。
    {"access_token":"CJ7yDymDAfSRz03W7zdX","refresh_token":"fGAv2qzuLnM030Brs8KFaIuY1Kd2P87sLFXI85lH","scope":"","token_type":"bearer","expires_in":1799}*
    呼び出しが成功すると、HTTP 応答コード 201 が返されます。 クライアントまたはサービス資格情報が無効な場合、呼び出しは HTTP 応答コード BAD_REQUEST (400)を返します。
  2. トークンを使用して、クラウド操作 API にアクセスします。
    前のステップで返されたアクセス・トークンを、クラウド操作 API 呼び出しの許可ヘッダーに組み込みます。 例:
    curl -k -v -H "Authorization: Bearer CJ7yDymDAfSRz03W7zdX" https://<tenantHost>/baw/dev/rest/bpm/wle/v1/user/current
    アクセス・トークンが無効であるか有効期限が切れている場合、呼び出しは HTTP 応答コード 302 を返します。
  3. リフレッシュ・トークンを使用してアクセス・トークンをリフレッシュします。
    OAuth 2.0 /token エンドポイントを使用します。
    curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
    -d grant_type=refresh_token -d refresh_token=fGU3UjAHG0XKTdnInU8ihqTLf48XJIzQtRUjNFVo
    -d client_id=<clientId> -d client_secret=<clientSecret>
    https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
    
    呼び出しは、新しいトークン・セットを返します。
    {"access_token":"DkhN7gg7mk2gsBjGi8ay","refresh_token":"ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC","scope":"","token_type":"bearer","expires_in":1799}
    リフレッシュ・トークンが無効であるか既に使用されている場合、またはクライアント資格情報が削除されたなどの理由で無効である場合、この呼び出しは HTTP BAD_REQUEST (400) 応答コードを返します。
  4. クライアント・アプリケーション処理の最後にリフレッシュ・トークンとアクセス・トークンを取り消します。

    クライアント・アプリケーションの処理が終了したら、OAuth 2.0 /revoke エンドポイントを使用して両方のトークンを取り消すことをお勧めします。 アクセス・トークンを取り消す前に、リフレッシュ・トークンを取り消してください。

    例えば、次の呼び出しを使用してリフレッシュ・トークンを取り消します。
    curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' 
    -d client_id=<clientId> -d client_secret=<clientSecret>
    -d token=ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC
    https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/revoke
    
    呼び出しは、常に正常な HTTP 応答コード (200 など) を返します。
    重要: API にアクセスした後、アクセス・トークンは有効期限が切れるまで有効なままです。

制限

同時に有効な権限付与 (アクセス・トークンとリフレッシュ・トークンのペア) の数が一日あたり数百個にシステム定義で制限されています。 これらの権限付与は、クライアント・アプリケーションおよびリソース所有者のユーザー名で追跡されます。 権限付与数の制限に達することはないと予想されています。 しかし、権限付与数の制限に達したことを示すメッセージが表示された場合、クライアント・アプリケーションで権限付与作成の設計を確認するか、IBM サポートにお問い合わせください。