OAuth 受信
OAuth 受信認証により、信頼できる外部アプリケーションが ServiceNow API に安全にアクセスでき、制御および許可された接続が確保されます。
- oauth_admin
- mi_admin
- admin (アドミン)
受信認証により、サードパーティシステムや他の ServiceNow® インスタンスなどの外部アプリケーションが ServiceNow API に安全に接続できます。受信認証により、信頼できるクライアントのみが制御された安全な方法で ServiceNow インスタンスにアクセスできることを確認します。 ServiceNow は、それぞれが特定の統合シナリオ向けに設計されたいくつかの OAuth 2.0 権限許可タイプをサポートしています。次の情報を使用して、ユースケースに最適な権限許可タイプを選択してください。
認証コード権限許可
| 理想的な使用シナリオ | 機能 |
|---|---|
| ユーザーの同意を得て、ユーザーの代わりにユーザーデータにアクセスする必要があるアプリケーション。 例:ユーザーの代わりに動作する Web、モバイル、またはデスクトップアプリケーション。 |
ユーザーがクライアントアプリケーションからログインプロセスを開始すると、 ServiceNow ログインページにリダイレクトされます。ユーザーがログインして同意すると、クライアントアプリケーションは認証コードを受け取ります。クライアントアプリケーションは、アクセストークンの認証コードを ServiceNow インスタンスと交換します。 認証コード権限許可は、ユーザー向け統合で最も安全で広く使用されているワークフローです。機密クライアント (クライアントシークレットを使用) と、Proof Key for Code Exchange (PKCE) を使用するパブリッククライアントの両方をサポートします。 |
認証コード権限許可のワークフローと構成の詳細については、次を参照してください。 認証コードの許可
クライアント認証情報の権限許可
| 理想的な使用シナリオ | 機能 |
|---|---|
| バックエンドサービスや自動システム統合など、ユーザーの関与なしに ServiceNow API にアクセスする必要があるクライアントアプリケーション。 | クライアントアプリケーションは、独自の認証情報 (クライアント ID とシークレット) を使用して、 ServiceNow インスタンスで直接認証します。認証されると、アプリケーションは ServiceNow API にアクセスするためのアクセストークンを受け取ります。 |
クライアント認証情報権限許可のワークフローと構成の詳細については、「 クライアント認証情報の権限許可」を参照してください。
サードパーティ ID トークンフロー
| 理想的な使用シナリオ | 機能 |
|---|---|
| ServiceNow が Azure AD や Okta などの外部 ID プロバイダーによって発行された ID トークンまたはアクセストークンを信頼するフェデレーション認証シナリオ。 | クライアントアプリケーションは、信頼できるサードパーティの ID プロバイダーから ID またはアクセストークンを取得し、 ServiceNow インスタンスに API 要求を行うときに認証ヘッダーに含めます。 ServiceNow トークンを検証し、信頼されている場合は、アサートする ID に基づいてアクセス権を付与します。これにより、システム間でシームレスなシングルサインオン (SSO) とフェデレーション認証が可能になります。 |
サードパーティトークンのフローと構成の詳細については、「サードパーティトークンの付与」を参照してください。
JWT ベアラー助成金
| 理想的な使用シナリオ | 機能 |
|---|---|
| ユーザーの操作や共有シークレットの保存を必要とせずに、ユーザーの代わりに、またはユーザー自身として、 ServiceNow リソースへの安全なアクセスを必要とするクライアントアプリケーション。 クライアント アプリケーションは、それが表すユーザーやシステムなど、ID 関連の要求を含む署名付き JSON Web トークン (JWT) を作成します。次に、それを ServiceNow インスタンスに提示して、アクセストークンを要求します。 |
|
JWT ベアラー権限許可のワークフローと構成の詳細については、「 JSON Web トークンベアラー権限許可」を参照してください。
リソース所有者のパスワード認証情報の付与
| 理想的な使用シナリオ | 機能 |
|---|---|
| アプリがユーザーの認証情報を直接収集する、制御された環境にある、信頼性の高い内部クライアントアプリケーション。 | クライアントアプリケーションは、ユーザーのユーザー名とパスワードを収集し、それらを ServiceNow インスタンスにリダイレクトしてアクセストークンを取得します。ワークフローはリダイレクト画面と同意画面をバイパスしますが、ユーザー認証情報をクライアントアプリケーションに公開します。 ServiceNow では、リソース所有者のパスワード認証情報の付与は、従来の環境または制御された環境でのみ実装することをお勧めします。 |
リソース所有者のパスワード認証情報付与のワークフローと構成の詳細については、「 リソース所有者のパスワード認証情報の付与」を参照してください。
暗黙的な権限許可
| 理想的な使用シナリオ | 機能 |
|---|---|
| 従来のシングルページアプリケーション (SPA) またはブラウザーベースのアプリでは、クライアントシークレットを安全に保存できず、軽量のクライアント側認証フローが必要です。 | ユーザーはブラウザーからログインします。クライアントアプリケーションは、ログイン後に中間認証コードのステップをバイパスして、URL で直接アクセストークンを受信します。 このフローはもともと、シークレットの安全な保存が不可能な、完全にブラウザで実行されるパブリッククライアント向けに設計されました。実装は簡素化されますが、ブラウザにトークンが公開されるため、傍受のリスクが高まります。セキュリティを強化するために、 ServiceNow は PKCE を使用して認証コード付与を実装することを推奨しています。 |
暗黙的な権限許可のワークフローと構成の詳細については、「 OAuth の暗黙的な権限許可」を参照してください。
OAuth スコープ
REST API の OAuth 認証スコープのサポートを詳しく調べることができます。OAuth スコープは、特定の REST API へのアクセスのみを提供します。詳細については、「REST API 認証スコープ」を参照してください。