OAuth 2.0
OAuth 2.0 を使用すると、ユーザーは、各リソース要求でログイン認証情報を入力するのではなく、トークンを取得することで、外部クライアントを介してインスタンスリソースにアクセスできます。
OAuth 統合を管理するには、security_admin ロールが必要です。次のようなシナリオで OAuth 2.0 を設定します。
- OAuth 外部クライアントシナリオ (受信)：インスタンスは、インスタンスからデータをプルするためのサードパーティクライアント用のエンドポイントを提供します。
- OAuth プロバイダーシナリオ (送信)：インスタンスがサードパーティプロバイダーからデータをプルします。
注:
トークンを初めて取得するには、ユーザー認証を行う必要があります。その後は、トークンの有効期限が切れるまでユーザーアカウントを使用して認証する必要はありません。
OAuth 2.0 は、シンプルなセキュリティフレームワークと高セキュリティフレームワークの両方でサポートされています。高セキュリティをお勧めします。高度なセキュリティが既に有効になっているバージョン、および高度なセキュリティをアクティブ化する方法について、情報を参照してください。
OAuth 2.0 実装の重要なコンセプト
| コンセプト | 説明 |
|---|---|
| リソース所有者 | 保護されたリソースへのアクセスを許可できるエンティティ。リソース所有者が個人である場合は、エンドユーザーと呼ばれます。リソース所有者は常にユーザーアカウントです。 |
| クライアント | リソース所有者の承認により、リソース所有者の代わりに保護されたリソースに対する要求を行うアプリケーション。 |
| リソースサーバー | 保護されたリソースをホストし、保護されたリソースへの要求を受け入れて応答できるサーバー。 |
| 認証サーバー | リソース所有者を正常に認証して認可を取得した後、クライアントにアクセストークンを発行するサーバー。 |
| 認証要求 | 保護されたリソースにアクセスするためにクライアントが必要とする権限。認証要求は常に、リソース所有者の代わりに動作するクライアントの ID と要求を許可する認証情報を含む HTTP POST メッセージです。 |
| 認証権限許可 | リソースにアクセスするための、リソース所有者からの認可を表す認証情報。認証権限許可は、ユーザーのログイン認証情報またはリフレッシュトークンのいずれかです。 |
| アクセストークン | 保護されたリソースにアクセスするためにクライアントが使用する安全な文字列。インスタンスは、有効な認証権限許可を持つクライアントにアクセストークンを発行します。各アクセストークンには、特定のスコープ、有効期間、およびその他の属性が含まれます。 デフォルトで、インスタンスが OAuth プロバイダーであるシナリオでは、インスタンスは 30 分の有効期間でアクセストークンを発行します。サードパーティのトークンの場合は 30 日間です。 |
| リフレッシュトークン | クライアントが追加のユーザー認証を要求せずに新しいアクセストークンを取得するために使用する認証情報。インスタンスは、初めてアクセストークンを持つことが許可されると、クライアントにリフレッシュトークンを発行します。 デフォルトで、インスタンスが OAuth プロバイダーであるシナリオでは、インスタンスは 100 日の有効期間でリフレッシュトークンを発行します。サードパーティのトークンの場合は 365 日間です。 |
| 自己署名証明書 | ServiceNow AI Platform は自己署名証明書をサポートしていません。OAuth クライアントは証明書トラストストアを使用せず、自己署名証明書を組み込んだ OAuth エンドポイントへの接続を許可しません。 |
| ユーザーエージェント | クライアントアプリケーション (多くの場合は Web サイト) へのアクセス権を委任するユーザー。アクセス権により、クライアントアプリケーションまたは Web サイトは、ユーザーがアクセス権を持つインスタンス内のデータへのアクセスを許可されます。ユーザーエージェントはシナリオで使用されます。 |
OAuth 権限許可タイプ
権限許可タイプは、クライアントがアクセストークンを取得する方法です。次の権限許可タイプがサポートされています。
- 認証コード：コンシューマーは最初に認証コードを取得し、それを使用してアクセストークンを取得します。OAuth プロファイルを指定し、この権限許可タイプを指定することができます。認証コードを使用するプロセスは、auth コードフローまたは認証コードフローとも呼ばれます。
- リソース所有者のパスワード認証情報：リソースのコンシューマーは、アクセストークンを取得するためのユーザー認証情報をすでに持っています。このプロセスは、パスワードフローとも呼ばれます。
- クライアント認証情報：リソースのコンシューマーは、アプリケーションレジストリにすでに設定されているクライアント ID とクライアントシークレットを使用します。
認証情報のストレージ
OAuth クライアントシークレットは password2 タイプフィールドとして格納され、KMF で暗号化されます。受信エンドポイント要求のチェックに使用されるユーザーパスワードは、ユーザーテーブルの password タイプフィールド (SHA 256) にハッシュ値として格納されます。この暗号化の詳細については、「KMF による Password2 暗号化」を参照してください。