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

Open Authorization (OAuth) 2.0 では、リソースの所有者がその保護リソースへのアクセス権限を付与するための方法がいくつか記載されています。IBM® Digital Business Automation on Cloud では、クライアント・アプリケーションがクラウド環境にアクセスする際の認証の権限付与タイプとして、リソース所有者パスワード資格情報 (ROPC) 権限付与タイプのみがサポートされます。

注: クラウド・サブスクリプションで OAuth 2.0 ベースの認証はデフォルトで使用不可になっています。使用したい場合は、IBM サポート・ポータルから要求を送信してください。

ROPC 権限付与タイプ

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

OAuth および ROPC の権限付与タイプについて詳しくは、OAuth 2.0 Authorization Framework を参照してください。資格情報 API について詳しくは、クラウド操作 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 サポートにお問い合わせください。