Postman を使用した OAuth のテストSummaryこの例では、API によって提供されるトークンを使用してインスタンスに対して認証を行うクライアントアプリケーションとして Postman を使用します。Instructions1) システム OAuth > アプリケーションレジストリに移動し、新しいレコードを作成します。 次のページで、[外部クライアント用の OAuth API エンドポイントを作成する] オプションを選択します。今のところ、設定する必要があるのは名前とリダイレクト URL だけです。この例では、名前を「Test」に設定するだけで、リダイレクト 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 要求に変更します。 例：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 になります-ステータスは任意の値に設定できますが、空白のままにすることはできません。 7) [トークンを要求] をクリックすると、ServiceNow ログインページを含むポップアップウィンドウが表示されます。 ここに認証情報を入力し、次のページで [許可] をクリックします。 8)手順4を繰り返すと、再び同じ結果が得られるはずです。 選択リストには他にも利用可能な権限許可タイプがありますが、サポートされているのはリソース所有者のパスワード認証情報と認証コードのみです。KB0745184を参照してください。Related Linksよく寄せられる質問 権限許可タイプの違いは何ですか? 権限許可タイプとは、単にアプリケーションがアクセストークンを取得する方法を指します。インスタンスがアクセストークンを付与するためには、関連付けられたユーザーがインスタンスへのアクセスをアプリケーションに承認していることを確認する必要があります。リソース所有者のパスワード認証情報を使用すると、認証情報が要求とともに渡されるため、認証情報が有効である限り、インスタンスはアプリケーションがそのユーザーとしてインスタンスにアクセスすることを承認します。この権限許可タイプでは、ユーザーの認証情報をクライアントアプリケーションに公開する必要があるため、認証コードの権限許可タイプがより一般的に推奨されます。この権限許可タイプでは、ユーザーはポップアップウィンドウに認証情報を入力するため、ユーザーの認証情報がクライアントアプリケーションに入力されることはありません。 認証コード権限許可タイプを使用して認証情報を提供する必要があります。それはどう違うのですか? ポップアップウィンドウに認証情報を入力すると、一意のトークン値を持つ認証コードエントリが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レコードで手動で調整できます。