Postman を使用した OAuth のテストSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } この例では、API によって提供されるトークンを使用してインスタンスを認証するクライアントアプリケーションとして Postman を使用します。 Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } すべてのリリース Instructions<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1) [システム OAuth] > [アプリケーションレジストリ] に移動し、新しいレコードを作成します。 次のページで、[外部クライアント用の OAuth API エンドポイントを作成する] オプションを選択します。今のところ、設定する必要があるのは名前とリダイレクト URL だけです。この例では、名前を「テスト」に設定するだけで、リダイレクトURLは次のようになります:https://getpostman.com/oauth2/callback *この URL はクライアントアプリケーションに固有のものです。 2) Postman アプリケーションを開き、https://<INSTANCE>.service-now.com/oauth_token.do への新しい POST 要求を作成します。 [認証] タブで [OAuth 2.0] を選択すると、右側にオプション ポップアップが表示され、[新しいアクセス トークンを取得] というボタンが表示されます。デフォルトでは、OAuth エンティティは「リソース所有者のパスワード認証情報」権限許可タイプを使用します。 -権限許可タイプはパスワード認証情報になります。-アクセストークンURLは https://<INSTANCE>.service-now.com/oauth_token.do-認証に使用するユーザーのユーザー名/パスワードを入力します。:クライアント ID とクライアントシークレットは、手順 1 で作成したoauth_entityレコードにあります。-クライアント認証は「クライアント認証情報を本文で送信」のままにしておくことができます。 3) [トークンを要求] をクリックすると、ServiceNow インスタンスの認証に使用できるリフレッシュトークンとアクセストークンの両方を含む応答が返されます。 4) [トークンを使用] を選択し、Postman のエンドポイント URL をクエリするレコードの GET 要求に変更します。 例：https://<INSTANCE>.service-now.com/api/now/table/incident/<INCIDENT SYS_ID> を取得 インシデントレコードデータが応答に表示される必要があります。 ...それでは、「認証コード」権限許可タイプを使用してみましょう。 5) oauth_entityテーブルのリストビューに移動し、[デフォルトの権限許可タイプ] 列をリストに追加します。ページが更新されたら、値を「認証コード」に設定します。 6) Postman に戻り、別の POST リクエストを /oauth_token.do に送信します。 [認証] タブで [新しいアクセストークンを取得] をクリックした後、いくつかの値を変更する必要があります。 :権限許可タイプは「認証コード」になります。-認証 URL は https://<INSTANCE>.service-now.com/oauth_auth.do になります。-State は任意の値に設定できますが、空白のままにすることはできません。 7) [トークンを要求] をクリックすると、ServiceNow ログインページのポップアップウィンドウが表示されます。 ここに認証情報を入力し、次のページで [許可] をクリックします。 8) 手順 4 を繰り返すと、同じ結果が得られるはずです。 選択リストで使用できる権限許可タイプは他にもありますが、サポートされるのはリソース所有者のパスワード認証情報と認証コードのみです。KB0745184を参照してください。 Related Links<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } よく寄せられる質問 助成タイプの違いは何ですか? 権限許可タイプとは、単にアプリケーションがアクセストークンを取得する方法を指します。インスタンスがアクセストークンを付与するには、関連付けられたユーザーがアプリケーションによるインスタンスへのアクセスを許可していることを確認する必要があります。リソース所有者のパスワード認証情報を使用すると、認証情報は要求とともに渡されるため、認証情報が有効である限り、インスタンスはアプリケーションにそのユーザーとしてインスタンスへのアクセスを許可します。この権限許可タイプでは、ユーザーの認証情報をクライアントアプリケーションに公開する必要があるため、一般的には認証コード権限許可タイプが推奨されます。この権限許可タイプでは、ユーザーはポップアップウィンドウに認証情報を入力するため、ユーザーの認証情報がクライアントアプリケーションに入力されることはありません。 認証コード権限許可タイプを使用して認証情報を入力する必要があります。それはどう違うのですか? ポップアップウィンドウに認証情報を入力すると、一意のトークン値を持つ認証コードエントリがoauth_credentialテーブルに作成されます。このトークン値は、アクセストークンとリフレッシュトークンの要求に使用されるクライアントアプリケーションに返されます。要求の本文は次のようになります。 {"grant_type":"authorization_code","code":"YkOfv3CfzSG7MPqCC2FuopN0GhCMiFzN4GXpguGH0w5jJ0sLBMoXEg6rj1nuqgQ4rC5C8rHmmJqfibzbE9ikdw","redirect_uri":"https://getpostman.com/oauth2/callback","client_id":"12345678910","client_secret":"xxxxxx"} インスタンスは認証コードを生成する前に最初にユーザーを認証しているため、認証コードを使用してユーザーの ID を検証し、インスタンスに対して認証できます。 ユーザー認証情報を提供せずにアクセストークンを取得する方法はありますか? 技術的には、はい、ただし必ずしも推奨されるわけではありません。oauth_entityレコードから、「OAuth 認証情報」というタイトルの関連リストがフォームにあります。ここで新しいエントリを作成すると (type=Authorization Code で)、上記の例と同様に、そのトークンを /oauth_token.do への POST 要求に手動で入力できます。他のヘッダー (特に client_id と client_secret) が正しく設定されている限り、インスタンスは、認証コードを作成したユーザーに対して有効なアクセス/リフレッシュ トークンを返します。このメソッドではトークン値が自動的に生成されないことに注意してください。oauth_credentialレコードに手動で入力する必要があります。この方法では基本的に、アドミニストレーターが別のユーザーに代わって、知らないうちにクライアントアプリケーションにインスタンスへのアクセス権を付与することができます。また、トークンはアドミンユーザーが手動で入力する必要があるため、インスタンスによって自動的に生成されるトークンほど安全ではない可能性があります。顧客にアドバイスするときは注意してください。 ServiceNow インスタンスはどのようにこれらのトークンを生成しますか? トークンはスクリプト可能クラスではないTokenGenerator.javaによって生成されます。これにより、ランダムなバイトのシーケンスが生成され、base64 でエンコードされた文字列として返されます。これはユーザーインターフェイスから実行できないため、顧客は手動で独自に作成するか、必要に応じてサードパーティのツール/プログラムを使用して生成する必要があります。Java の例: import java.security.SecureRandom;import org.apache.commons.codec.binary.Base64; public class generateToken { public static void main(String a[]){ String s = generateRandom(64); System.out.println(s); } public static String generateRandom(int bits) { return Base64Encoded(randomKey(bits)); } public static String Base64Encoded(byte[] bytes) { Base64 base64 = new Base64(0, null, true); return base64.encodeAsString(bytes); } public static byte[] randomKey(int size) { try { SecureRandom random = SecureRandom.getInstance("SHA1PRNG"); byte[] randomKey = new byte[size]; random.nextBytes(randomKey); return randomKey; } catch (Exception e) { } return null; }} アクセストークンとリフレッシュトークンの違いは何ですか? アクセストークンは、ユーザーを認証するために実際に使用されるものであり、リフレッシュトークンよりも有効期間がはるかに短いはずです。デフォルトでは、ServiceNow はこれを 30 分に設定します。このトークンの有効期限が切れると、POST 要求をリフレッシュトークンとともに API エンドポイントに送信して、新しく生成されたアクセストークンを返すことができます。デフォルトでは、これは 100 日に設定されています。これらは両方ともoauth_entityレコードで手動で調整できます。