認証・認可（Basic・OAuth・JWT・統合ユーザー）

この章の結論

• Fusion の REST API は Basic 認証・SAML 2.0・JWT・OAuth 2.0（すべて SSL 上） を受け付けます。本番の連携では、パスワードを持ち回らない OAuth 2.0（JWT ユーザー・アサーション） を第一候補にします。
• どの方式でも、API は Fusion のユーザーとして 実行されます。何ができるかは、そのユーザーのロール（職務ロール・権限・データアクセス）で決まります。
• 連携には人のアカウントを使わず、用途別の統合ユーザー を作り、必要な権限だけを付けます。
• パスワード・証明書・クライアント資格情報には期限があります。期限切れは連携全体の停止（401）に直結するため、運用で管理します。

全体像

認証と認可の分担

段階	何を確かめるか	Fusion での仕組み	失敗したとき
認証	誰が呼んでいるか	Basic・OAuth 2.0・JWT・SAML・WS-Security	401 Unauthorized
認可	何をしてよいか	ロール（職務ロール・権限）とデータアクセス（BU・元帳など）	403 Forbidden、または 0 件

REST API は OWSM のポリシー oracle/multi_token_over_ssl_rest_service_policy で保護されています。このポリシーが受け付ける方式は次の 4 つです。

方式	仕組み	向く用途
Basic 認証（SSL 上）	ユーザー名:パスワード を Base64 にして Authorization: Basic ヘッダーで送る	開発・検証、簡易な連携
OAuth 2.0	OCI IAM のアイデンティティ・ドメインからアクセス・トークンを取得し、Authorization: Bearer で送る	本番の連携、カスタム・アプリ
JWT（SSL 上）	ユーザー名と有効期限を持つトークンを Bearer で送る	拡張機能などからの呼び出し
SAML 2.0 ベアラー・トークン（SSL 上）	SAML アサーションを Bearer で送る	フェデレーション環境

26D 時点の公式ドキュメントでは、/api/boss/data/objects/.../v1/... 形式の新しいリソース（ドキュメント上の呼称は Spectra）は OAuth 2.0 が必須 です。

OAuth 2.0 の付与タイプ（グラント・タイプ）

付与タイプ	誰として動くか	使える対象（26D 時点）	典型的な用途
認可コード（PKCE 付きを含む）	ブラウザでログインした利用者	Fusion の REST、Spectra	利用者が操作するカスタム・アプリ
JWT ユーザー・アサーション	アサーションに書いたユーザー	Fusion の REST、Spectra	サーバー間の連携（OIC など）
クライアント資格証明	ユーザーなし（クライアントそのもの）	Spectra のみ	Spectra の API を使うバッチ

/fscmRestApi/... などの従来の REST に対して、公式ドキュメントはクライアント資格証明を対応付与タイプに挙げていません。サーバー間連携では JWT ユーザー・アサーション を使うのが基本です。

設定・実装の手順

1. 統合ユーザーを作り、権限を設計する

1. ナビゲータ > ツール > セキュリティ・コンソール（Security Console）> ユーザー（Users）で、統合専用のユーザーを作成します（例：INT_AP_USER）。
2. 連携する業務オブジェクトに必要な職務ロールと、データアクセス（BU・元帳など）を付けます。ロールは必要な権限だけを持つカスタムロールにします（セキュリティ設計）。
3. OIC の ERP Cloud アダプタで使う場合は、公式ガイドが挙げる次のロールを確認します。

ロール・権限	目的（公式ガイドより）
Integration Specialist	統合用の職務ロール。データロールを持たないため、他のロールを継承する職務ロールに組み込んで使う
業務オブジェクト別のデータアクセス	連携するオブジェクトに応じて付与する
AttachmentsUser	ERP Integration Service からログ・出力ファイルをダウンロードするため
SOAOperator	ERP のビジネスイベントを受け取るため
FND_MANAGE_CATALOG_SERVICE_PRIV	Web サービス・カタログの管理（イベント用の権限ではない）

4. ビジネスイベントの有効化に使う erpBusinessEvents リソースには、権限「Access FSCM Integration Rest Service（FUN_FSCM_REST_SERVICE_ACCESS_INTEGRATION_PRIV）」が必要です。
5. 用途ごとにユーザーと接続を分けます。公式ガイドも、GL 用・プロジェクト用など役割別の統合ユーザーと OIC 接続を作る構成を例示しています。

ノート

公式ガイドには、Integration Specialist を導入コンサルタント系のロールに組み込む例も載っています。開発環境ではそれでもかまいませんが、本番では必要な権限だけのカスタムロールにします。

2. パスワードと資格情報の期限を管理する

• 統合ユーザーにもパスワード・ポリシー（有効期限など）が適用されます。設定場所と既定値はリリースにより異なるため、公式ドキュメント（Securing ERP）で確認し、統合ユーザーの扱いを決めておきます。
• 期限切れやロックは、すべての連携の 401 エラーとして現れます。パスワード・証明書・クライアント資格情報の期限を運用カレンダーで管理し、更新手順を作っておきます。
• 資格情報はコードに書かず、OIC の接続定義や秘密情報の保管庫（OCI Vault など）に置きます。

3. Basic 認証で呼ぶ

最も簡単な方式です。HTTPS が前提です。curl では -u を使うと Authorization: Basic ヘッダーが作られます（「コード例」参照）。

4. OAuth 2.0：機密アプリケーションを登録する

公式手順（Configure OAuth to Access Oracle Fusion Cloud Applications REST APIs）の要点です。画面名は英語 UI のまま記載します。

1. Fusion に関連付いたアイデンティティ・ドメインに管理者でサインインし、Integrated applications > Add application を選びます。
2. Confidential Application を選び、Launch workflow で名前を入力して登録します。
3. OAuth configuration で Configure this application as a client now を選びます。
4. Authorization で付与タイプ（Authorization code・JWT assertion・Client credentials）を選びます。
5. JWT を使う場合は Client type を Trusted にし、Import certificate で署名用の公開証明書を登録します。証明書の別名は、JWT ヘッダーの kid と同じにします。
6. Token issuance policy で Authorized resources を Specific にし、Add scope で対象のリソース・アプリケーション（Fusion Applications など）を追加します。
7. Actions > Activate で有効化し、Client ID を控えます。

スコープは、ドメインの Oracle Cloud Services で Oracle Applications Cloud (Fusion) を開き、プライマリ・オーディエンスとスコープを連結して作ります。公式の例は urn:opc:resource:fa:instanceid=<インスタンスID> と urn:opc:resource:consumer::all の連結です。値は環境で必ず確認します。トークンの発行先は https://<アイデンティティ・ドメインのURL>/oauth2/v1/token です。

注意

公式手順は「OAuth トークン発行者（issuer）の名前を変更しない」よう注意しています。また、クライアントの認証には、クライアント・シークレットよりクライアント・アサーション（署名付き JWT）が推奨されています。

5. JWT ユーザー・アサーションでトークンを取る

• ユーザー・アサーション：「どの Fusion ユーザーとして動くか」を書き、自分の秘密鍵で署名した JWT です。
• クライアント・アサーション：「このクライアント・アプリである」ことを示す署名付き JWT です。
• 2 つを付けてトークン・エンドポイントに POST すると、アクセス・トークン（公式例では expires_in が 3600 秒）が返ります。アサーションに必要なクレームと署名方式は、公式の「Client/User JWT Assertion」で確認します。
• OIC の ERP Cloud アダプタでは、接続のセキュリティ・ポリシーに OAuth using JWT User Assertion を選ぶと、この方式を使えます。アダプタが選べるポリシーは、ほかに Username Password Token、Username Password Token With PGP Key Support、OAuth Authorization Code Credentials です。

6. クライアント資格証明（Spectra の API 向け）

ERP Data Integrations の Spectra API の手順では、次の流れが示されています。

1. 付与タイプ client_credentials の機密アプリケーションを作ります。
2. トークンを Fusion と IAM の両方で検証するサービスでは、ユーザー名をクライアント ID と同じにした Fusion ユーザー を作ります（セキュリティ・コンソール > ユーザー > Add User Account）。
3. スケジュール済プロセス「Import User and Role Application Security Data」を実行して反映します。
4. grant_type=client_credentials と URL エンコードしたスコープ（公式例：urn:opc:resource:fusion:<ポッド名>:erp/）でトークンを取得します。

7. Fusion の JWT

公式の「Use JSON Web Token for Authorization」は、JWT を「ユーザー名と有効期限を運ぶトークン」と説明しています。JWT 自体はユーザーを認証するものではなく、サーバーとユーザー名を共有する仕組みです。Postman では認証タイプに Bearer Token を選んで使います。プログラムからの利用例として、公式ページは Groovy スクリプトから REST を呼ぶ方法の説明にリンクしています。

8. SOAP の WS-Security

SOAP では、クライアント側の OWSM ポリシーで認証情報の載せ方が決まります。

クライアント・ポリシー	認証情報の場所	準備
oracle/wss_username_token_over_ssl_client_policy	SOAP ヘッダー（WS-Security の UsernameToken）	HTTPS のみ。追加設定なし
oracle/wss_http_token_over_ssl_client_policy	HTTP ヘッダー（Basic）	HTTPS のみ
oracle/wss_saml_token_bearer_over_ssl_client_policy	SAML トークン	クライアントの鍵ストアが必要。サーバーにクライアント証明書を登録
oracle/wss11_username_token_with_message_protection_client_policy	UsernameToken＋署名・暗号化	サーバーの公開鍵（WSDL 内の証明書）をクライアントに取り込む

ヘッダーの書き方は SOAP Web サービス で説明します。

9. 証明書を管理する

• JWT 署名用の証明書：自分で鍵ペアを作り、公開証明書を機密アプリケーションに登録します。更新時は kid と別名の対応を崩さないようにします。
• SOAP のメッセージ保護用：サーバーの証明書は WSDL の dsig:X509Certificate から取り出し、BEGIN CERTIFICATE／END CERTIFICATE の行で囲んでクライアントの鍵ストアに取り込みます。
• 外部への HTTPS 呼び出し：OIC から外部の HTTPS サービスを呼ぶ場合は、必要に応じて OIC に証明書をアップロードします。

接続元の制限にも注意します。ERP Cloud アダプタの前提作業には「ロケーション・ベースのアクセス制御（LBAC）の状態確認」が含まれています。LBAC を有効にしている環境では、接続元の IP アドレスの扱いを事前に確認します。

コード例

Basic 認証（実機とモック API）

実機：環境変数から資格情報を読む

export FA_HOST="https://<your-pod>.fa.<region>.oraclecloud.com"
export FA_USER="INT_AP_USER"          # 例
read -s FA_PASS && export FA_PASS     # パスワードは入力して環境変数へ

curl -s -u "$FA_USER:$FA_PASS" \
  "$FA_HOST/fscmRestApi/resources/11.13.18.05/invoices?limit=1&onlyData=true"

モック API：Basic 認証と Bearer の両方を試す

export BASE="https://<このサイトのURL>/api/mock/fscmRestApi/resources/11.13.18.05"

# 認証ヘッダーなし → 401
curl -s -o /dev/null -w "%{http_code}\n" "$BASE/invoices?limit=1"

# Basic 認証
curl -s -u learner:welcome1 "$BASE/invoices?limit=1&onlyData=true"

# Bearer（モックは任意の文字列を受け付ける）
curl -s -H "Authorization: Bearer dummy-token" "$BASE/invoices?limit=1&onlyData=true"

JWT ユーザー・アサーションでトークンを取得して呼ぶ

トークン取得（アサーションは別途作成して環境変数に入れておく）

curl -s -X POST "$IDCS_URL/oauth2/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" \
  --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
  --data-urlencode "assertion=$USER_ASSERTION" \
  --data-urlencode "scope=$FA_SCOPE" \
  --data-urlencode "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \
  --data-urlencode "client_assertion=$CLIENT_ASSERTION"
# 応答例：{"access_token":"eyJ...","token_type":"Bearer","expires_in":3600}

token_client.py：トークンを使い回し、401 なら 1 回だけ取り直す

import os
import time
import requests

IDCS_URL = os.environ["IDCS_URL"]      # https://idcs-xxxx.identity.oraclecloud.com
FA_HOST = os.environ["FA_HOST"]        # https://<your-pod>.fa.<region>.oraclecloud.com

_token = {"value": None, "expires_at": 0}

def get_token() -> str:
    # 期限の 60 秒前までは同じトークンを使い回す
    if _token["value"] and time.time() < _token["expires_at"] - 60:
        return _token["value"]
    resp = requests.post(
        f"{IDCS_URL}/oauth2/v1/token",
        data={
            "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
            "assertion": os.environ["USER_ASSERTION"],
            "scope": os.environ["FA_SCOPE"],
            "client_assertion_type": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
            "client_assertion": os.environ["CLIENT_ASSERTION"],
        },
        timeout=30,
    )
    resp.raise_for_status()
    body = resp.json()
    _token["value"] = body["access_token"]
    _token["expires_at"] = time.time() + int(body.get("expires_in", 3600))
    return _token["value"]

def fa_get(path: str, params: dict | None = None) -> dict:
    for attempt in range(2):
        headers = {"Authorization": f"Bearer {get_token()}"}
        r = requests.get(f"{FA_HOST}{path}", params=params, headers=headers, timeout=60)
        if r.status_code == 401 and attempt == 0:
            _token["value"] = None      # トークン失効の可能性 → 取り直して再試行
            continue
        r.raise_for_status()
        return r.json()
    raise RuntimeError("認証に失敗しました")

if __name__ == "__main__":
    data = fa_get("/fscmRestApi/resources/11.13.18.05/invoices",
                  {"limit": 1, "onlyData": "true"})
    print(data["count"])

実務では、ユーザー・アサーションも有効期限付きで都度生成します。生成処理は秘密鍵を扱うため、鍵の保管場所（Vault など）とあわせて設計します。

落とし穴とベストプラクティス

よくあるミス

• 担当者個人のアカウントで連携を動かす：異動・退職でアカウントが無効になり、連携が止まります。統合ユーザーを使います。
• 管理者ロールを付けっぱなしにする：漏えい時の影響が大きくなります。必要な権限だけのカスタムロールにします。
• 403 をロール不足だけだと思い込む：データアクセス（BU・元帳など）の不足でも起きます。公式のステータスコード一覧は、米国の輸出管理規制に沿わない場所からのアクセスでも 403 になり得ると注記しています。
• トークンを毎回取得する：トークン・エンドポイントの負荷と遅延が増えます。有効期限まで使い回します。
• JWT の有効期限と時刻のずれ：署名側サーバーの時刻がずれると、作ったアサーションが期限外と判定されます。NTP で時刻を合わせます。
• バニティ URL で接続する：連携の接続にはアプリケーション URL を使います。

• 方式を環境ごとにそろえる：開発は Basic、本番は OAuth のように変えると、本番切替で初めて問題が出ます。テスト環境から本番と同じ方式にします。
• ログに資格情報を出さない：Authorization ヘッダーやトークンをログに出力しないよう、HTTP クライアントのデバッグ設定に注意します。
• 四半期アップデート後の確認：認証まわりの設定変更やリリースの影響は、テスト環境で連携の疎通確認を行います。

試験対策ポイント

• 対応する試験：OIC 模擬テスト（ERP Cloud アダプタの接続とセキュリティ・ポリシー、統合ユーザーの前提）
• 覚えるポイント
  • REST の認証は Basic・SAML・JWT・OAuth 2.0（いずれも SSL 上）。Spectra のリソースは OAuth 必須。
  • サーバー間の OAuth は JWT ユーザー・アサーション。クライアント資格証明は 26D 時点で Spectra のみ。
  • ERP Cloud アダプタのセキュリティ・ポリシー 4 種と、イベント受信に SOAOperator、ログ取得に AttachmentsUser が必要なこと。
  • SOAP の UsernameToken は SOAP ヘッダー、HTTP トークンは HTTP ヘッダーに認証情報を載せる。

公式ドキュメント

• Quick Start（REST API for Oracle Fusion Cloud Financials 26D）
• Configure OAuth to Access Oracle Fusion Cloud Applications REST APIs
• Use JSON Web Token for Authorization
• Retrieve Bearer Token Using IDCS OAuth 2.0 REST API
• Client/User JWT Assertion（Identity Cloud Service）
• Static JAX-WS Proxy Client（SOAP のクライアント・ポリシー）
• Assign Required Roles to an Integration User（ERP Cloud アダプタ）
• Status Codes

関連ページ

• セキュリティの基本（ロールベースアクセス制御）
• セキュリティ設計（カスタムロール・データアクセス・監査）
• セキュリティ演習：カスタムロールとデータアクセスを設定する
• 接続とアダプタ（ERP Cloud アダプタ・接続エージェント）
• SOAP Web サービス