OAuth設定はtypeで役割を見分ける（oauth_entity）

2026年6月27日 08:58

ServiceNow で外部システムと連携しようとすると、必ず「認証」の話になります。Table API や Scripted REST API、送信側の REST Message を組むとき、その土台になるのが OAuth 2.0 の設定です。ServiceNow ではこの設定を oauth_entity（アプリナビ「System OAuth」配下）という1つのテーブルにまとめて持っています。

この記事は、REST 連携は触ったことがあるが、OAuth の設定がどのテーブルに、どんな形で保存され、「ServiceNow が呼ぶ側」なのか「呼ばれる側」なのかをどう見分けるのかを確認したい管理者・開発者を想定しています。PDI（Zurich / OOTB）で oauth_entity を実際に開き、type フィールド1つで役割が分かれること、PDI 実機での件数分布、主なフィールドとトークンの有効期間を順に確認します。

この記事で分かること

OAuth の設定は oauth_entity の1行＝1つのOAuth連携で保存され、type で役割が分かれること
type には OAuth Client（ServiceNowが呼ぶ側）/ OAuth Provider（呼ばれる側）/ External OIDC Provider（SSO/ログイン） があること
PDI 実機の 18件中9件が OAuth Client、6件が External OIDC Provider、3件が OAuth Provider という分布
client_secret は password 型（暗号化保存・マスク） で、画面でも値が見えない設計であること
トークンの既定有効期間が access_token=30分 / refresh_token=100日 であること
Azure AD・Okta・Mobile API といった OOTB 例がどの type に属するか

この記事の内容は ServiceNow の PDI（Personal Developer Instance）Zurich（ズーリッヒ）リリースの OOTB（初期設定）で確認した個人メモです。本番環境やカスタマイズ済み環境では、フィールド・選択肢・件数が異なる場合があります。なお、秘密情報の保護のため、client_id や client_secret といった実値は本記事では一切掲載しません。

oauth_entity とは：OAuth 連携を1行ずつ持つテーブル

oauth_entity は、ServiceNow が関わる OAuth 2.0 連携を1件＝1レコードで保存するテーブルです。下の実画面は、その1件（外部 IdP の Azure AD でログインするための設定）をフォームで開いたものです。

Name・Client ID・Client Secret・Active といった項目が並びます。Client ID は OOTB ではまだ差し込み用のプレースホルダのままで、Client Secret は黒丸でマスクされています（後述のとおり password 型）。このように oauth_entity は「OAuth 連携1つ分の設定」を1行で持ちます。

PDI（Zurich / OOTB）には、すでに 18件の設定が入っていました。ポイントは、1つのテーブルに役割の違うものが同居していることです。たとえば「ServiceNow が外部の Slack を呼ぶための設定」も、「外部の Azure AD でログインするための設定」も、どちらも同じ oauth_entity の行として保存されています。それらを見分ける鍵が type フィールドです。

type で役割が分かれる：呼ぶ側か、呼ばれる側か

oauth_entity を type でグループ化すると、役割ごとの内訳が見えます。

PDI 実機の 18件は、表示ラベルで見ると次の3つに分かれていました。

OAuth Client（9件）… ServiceNow が外部 API を呼ぶ側です。ServiceNow 自身がクライアントとなり、client_id と client_secret を持って外部からアクセストークンをもらいます。Mobile API・ServiceNow SDK・Trino Connector などが該当します。
OAuth Provider（3件）… 外部のクライアントが ServiceNow の API を呼ぶ側です。外部アプリに ServiceNow へのアクセスを許可するエンドポイント設定で、Sidebar Slack や Microsoft Teams Graph 連携が該当しました。
External OIDC Provider（6件）… 外部 IdP による SSO/ログイン用です。Azure AD・Okta・Auth0・Google・ADFS が並び、ユーザーが外部の認証基盤でログインするための設定です。

なお内部の type 値で見ると、client（9件）と oauth_provider（9件）の2値です。一覧の Type 列では oauth_provider の9件が「External OIDC Provider（6件）」と「OAuth Provider（3件）」に分かれて表示されていました。「呼ぶ側＝client」「呼ばれる/ログインされる側＝oauth_provider」と押さえると整理しやすいです。

どの type の設定か実機で見分ける

役割で絞り込むと、それぞれの設定がはっきり分かれます。type=oauth_provider で絞ると、外部から呼ばれる側（OAuth Provider）と SSO ログイン用（External OIDC Provider）がまとまって表示されます。

External OIDC Provider の OOTB テンプレートは Client ID が差し込み用のプレースホルダのままで、利用時に各 IdP の値を入れて使う形になっています。OAuth Provider の1件（外部アプリが ServiceNow を呼ぶための設定）をフォームで開くと、Default Grant type やトークン関連の項目が確認できます。

なお type=client（OAuth Client）の一覧には、ServiceNow が外部を呼ぶための自動生成された Client ID が並びます。これは秘匿に近い値のため、本記事では一覧画面の掲載は控え、フィールドの意味だけを次に説明します。

主なフィールド：秘密鍵は見えない設計

oauth_entity には 45 個のフィールドがあります。連携の中身を決める主なものは次の通りです。

特に重要なのが client_secret です。これは型が password（password2） で、データベース上は暗号化して保存され、フォームを開いても値はマスクされます。つまり、いったん登録した秘密鍵は管理者でも画面から読み出せません。client_id も既定では自動生成され、これらの実値を外部に漏らさない設計になっています（本記事でも値は載せていません）。フィールドの定義は dictionary で確認できます。

フィールド一覧は次のURLで確認できます（先頭の <YourInstance> は自分のインスタンスに置き換えてください）。

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=oauth_entity^elementISNOTEMPTY

トークンの有効期間：30分と100日

OAuth では、アクセストークンを使って API を呼びます。oauth_entity はそのトークンの有効期間も持っています。

PDI（Zurich / OOTB）の既定値は、access_token_lifespan=1800秒（30分）、refresh_token_lifespan=8640000秒（100日） でした。アクセストークンは短命で、期限が切れたらリフレッシュトークンで再発行する、という一般的な OAuth の考え方がそのまま既定値になっています。OIDC ログイン用の id_token は1日です。概念としての取得の流れは次の通りです。

なお、実際に取得済みのトークンは別テーブル oauth_credential に保管されます（PDI では0件＝まだ認可していない状態でした）。また、エンドポイントごとの詳細設定は oauth_entity_profile（PDI で9件）に分かれて持ちます。各 grant type の内部処理や SSO の実フローは、本記事の検証範囲外です。

実機で確認するときに見るべきURL

最後に、今回見た画面を自分のインスタンスで開くためのURLをまとめます（<YourInstance> は置き換えてください）。

# OAuth 設定の一覧（type順）
https://<YourInstance>/oauth_entity_list.do?sysparm_query=ORDERBYtype

# type でグループ化（役割別の件数）
https://<YourInstance>/oauth_entity_list.do?sysparm_query=GROUPBYtype

# oauth_entity のフィールド定義
https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=oauth_entity^elementISNOTEMPTY

OAuth の公式の考え方は ServiceNow 公式の OAuth 2.0（Zurich）でも説明されています。

まとめ

OAuth の設定は oauth_entity の1行＝1連携で保存され、type で役割が分かれる。
type は OAuth Client（ServiceNowが呼ぶ側・9件）/ OAuth Provider（呼ばれる側・3件）/ External OIDC Provider（SSO・6件）。内部値は client / oauth_provider の2つ。
client_secret は password 型で暗号化・マスクされ、登録後は画面からも読めない。
トークンの既定は access_token=30分 / refresh_token=100日 / id_token=1日。
取得済みトークンは oauth_credential、エンドポイント詳細は oauth_entity_profile に分かれて持つ。

OAuth の設定が分かると、Scripted REST API（受信側）・REST Message（送信側）という REST 連携が、「どちら向きで、どう認証するか」という形でつながって見えてきます。