Pega 認証設計：SAML SSO と OAuth 2.0 の使い分けと落とし穴
対話型のブラウザログインには SAML/OIDC、サービス間や API 連携には OAuth 2.0 と、Pega の認証は用途で設計を分けるのが基本です。認証サービスの選定と IdP 連携時の Access Group マッピング、そしてよくある落とし穴を LSA の視点で整理します。
結論から：認証は「用途」で設計を分ける
Pega の認証設計で最初に決めるべきは、認証方式そのものではありません。「誰が・何のために認証するのか」という用途の切り分けです。ここを曖昧にしたまま「とりあえず SSO を入れる」「既存の Basic 認証で API もつなぐ」と進めると、後から作り直す羽目になります。
結論を先に言うと、判断の起点はシンプルです。
人がブラウザで対話的にログインするなら SAML 2.0 / OIDC で IdP フェデレーション。サービス間・API 連携なら OAuth 2.0（Client Credentials / JWT Bearer）。ひとつの認証サービスで両方を賄おうとしない。
Pega は「認証サービス（Authentication Service）」という設定単位で認証方式を構成します。用途ごとに認証サービスを分けて定義するのが設計の型であり、ここを分離できるかどうかで保守性とセキュリティが大きく変わります。本記事では、この使い分けと IdP 連携時のマッピング設計、そしてよくある落とし穴を LSA の視点で整理します。
Pega の「認証サービス」という考え方
Pega では認証方式を、アプリケーションのロジックに直接埋め込むのではなく、認証サービス（Authentication Service）という独立した設定単位として定義します。SAML 用・OIDC 用の認証サービスや、API 連携向けの OAuth 2.0 クライアント登録を、それぞれ用途に応じて構成し、ログイン経路や API エンドポイントに割り当てる、という構造です。
この「認証を外出しする」設計により、認証方式の変更（たとえば IdP の切り替え）がアプリケーションのビジネスロジックに波及しません。裏を返すと、用途ごとに認証サービスを分けておかないと、この疎結合のメリットを享受できないということでもあります。ブラウザログインと API 認証を無理にひとつの経路に押し込むと、一方の要件変更がもう一方を巻き込みます。
認証サービスの種別・OAuth 2.0 クライアント登録が対応するグラント・トークンプロファイルの機能は Pega のバージョンによって差があります。設計は必ず対象バージョンで実際に使える機能を確認してから固めてください。
ブラウザの対話ログインは SAML 2.0 / OIDC
人がブラウザから Pega にログインする経路は、IdP（Identity Provider）にフェデレーションするのが基本です。Pega 側にパスワードを持たせず、企業の IdP（Azure AD / Entra ID、Okta、ADFS など）に認証を委ね、その結果を受け取ります。
- SAML 2.0 — 企業内 SSO で長く使われてきたフェデレーションプロトコル。IdP が発行する SAML アサーションを Pega が検証してログインさせます。
- OIDC（OpenID Connect） — OAuth 2.0 を土台にした認証レイヤ。ID トークン（JWT）でユーザーの身元を伝えます。モダンな IdP との連携で採用が増えています。
どちらを選ぶかは、多くの場合接続先 IdP がどちらを推奨・サポートしているかで決まります。新規で選択の自由があるなら OIDC が扱いやすい場面が多いですが、既存の企業 SSO 基盤が SAML 前提なら SAML に合わせます。重要なのは、この経路の目的は「人の対話ログイン」であり、API 認証をここに相乗りさせないことです。
IdP クレームから Access Group を決めるマッピング設計
SSO の設計で最も肝になるのが、IdP が返すクレーム（属性）から Pega の Access Group と Operator をどう決めるかというマッピングです。認証が通っただけでは不十分で、「そのユーザーがどの権限セット（Access Group）で、どの Operator として振る舞うか」を確定させて初めて業務ができます。
ここで最初に決めるべき分岐が、Operator を事前登録するか、Just-in-Time（JIT）で自動生成するかです。
| 観点 | 事前登録（Pre-provisioning） | JIT 自動生成 |
|---|---|---|
| Operator の用意 | 初回ログイン前に Pega 側で作成 | 初回ログイン時にクレームから自動作成 |
| 運用負荷 | 入退社のたびに手当てが要る | IdP 側の管理に一本化できる |
| 制御の細かさ | Operator ごとに細かく設定可 | クレーム→属性のマッピング設計に依存 |
| 向く規模 | 少人数・厳格に管理したい | 大規模・頻繁な異動がある |
| 前提 | ― | クレーム→Access Group の設計が必須 |
大規模組織や異動が多い環境では JIT が有利ですが、JIT を選ぶならクレームから Access Group を導出するルールを明示的に設計する必要があります。ここを設計せずに JIT を有効にすると、全員が既定の Access Group に落ちる、という後述の典型的失敗を招きます。
サービス間・API 認証は OAuth 2.0
システムが Pega の API を呼ぶ、あるいは Pega が外部サービスを呼ぶ——こうしたサービス間・非対話の連携は OAuth 2.0 を使います。ブラウザ SSO とはまったく別の認証サービスとして構成します。
- Client Credentials グラント — クライアント（システム）自身の資格情報でトークンを取得する、サービス間連携の標準的な方式。バックエンド同士の M2M（Machine to Machine）連携に向きます。
- JWT Bearer グラント — 署名付き JWT をアサーションとしてトークンと交換する方式。既に信頼関係のある発行元が主張する ID を前提にトークンを得たいケースで使います。
Pega では OAuth 2.0 の設定を OAuth 2.0 クライアント登録（OAuth 2.0 client registration） として管理し、どのグラントを許可するか、トークンの有効期間をどうするかを定義します。Infinity ‘25 時点で選べるグラントは authorization code / client credentials / password credentials / SAML bearer / JWT bearer / custom bearer で、サービス間連携では主に Client Credentials と JWT Bearer を使います。Basic 認証（ID/パスワードをリクエストに載せる方式）を API 連携に使い続けるのは典型的なアンチパターンです。動きはしますが、資格情報がリクエストごとに流れ、失効やスコープ制御ができず、監査もしづらくなります。連携相手が OAuth 2.0 に対応しているなら、迷わず OAuth 2.0 に寄せます。
使い分けの早見表
| 判断ポイント | ブラウザ SSO | サービス間・API 認証 |
|---|---|---|
| 主体 | 人（対話的） | システム（非対話） |
| 方式 | SAML 2.0 / OIDC | OAuth 2.0 |
| 代表的なグラント / 連携 | IdP フェデレーション | Client Credentials / JWT Bearer |
| 認証サービス | SSO 用に分けて定義 | API 用に分けて定義 |
| 身元の確定 | クレーム→Access Group / Operator | クライアント登録＋スコープ |
| ログアウト | SLO を設計 | トークン失効・リフレッシュを設計 |
| アンチパターン | 全員が既定 Access Group | Basic 認証の使い回し |
上の 2 列を「ひとつの認証サービスで兼ねよう」としないこと——これが設計の型です。用途が違えば認証サービスを分ける、と機械的に決めてしまうのが安全です。
よくある失敗
認証設計の失敗は、経験上ほぼ 3 つに集約されます。
失敗1：トークンの失効・リフレッシュ設計を欠く
OAuth 2.0 を入れたものの、アクセストークンの有効期間やリフレッシュの扱いを設計していないパターンです。有効期間を無限に近く長くすればセキュリティが緩み、短くすればリフレッシュ設計がないと連携が途中で切れます。トークンのライフサイクル（発行・有効期間・リフレッシュ・失効）は、認証を入れる時点で必ず一緒に設計してください。「つながった」で止めると、本番でトークン切れの障害として跳ね返ってきます。
失敗2：IdP グループを Access Group に紐付けず、全員が既定グループに落ちる
SSO 連携で最も多い落とし穴です。IdP 側のグループ・ロールを Pega の Access Group にマッピングしないまま JIT を有効にすると、認証は全員通るのに、全員が同じ既定の Access Group に入ってしまう。結果として、権限分離が効かず、本来見えてはいけない機能やデータに全員がアクセスできる、という重大な事故になります。クレーム→Access Group のマッピングは「あとで詰める」ではなく、SSO 設計の中核として最初に固めます。
失敗3：ログアウト（SLO）を考慮しない
ログインだけ設計してログアウトを忘れる、というのも定番です。SSO 環境では、Pega からログアウトしても IdP のセッションが生きていると再ログインで素通しされる、あるいは他アプリのセッションが残る、といった挙動になります。SLO（Single Log-Out）をどう扱うか——Pega のセッションだけ切るのか、IdP セッションまで連動させるのか——を要件として明示しておく必要があります。共用端末やコールセンターのような環境では特に重要です。
設計を固める前に：バージョン差を確認する
繰り返しになりますが、認証サービスの種別・OAuth 2.0 クライアント登録が対応するグラント・トークンプロファイル機能は Pega のバージョンによって異なります。ブログや古いドキュメントの手順をそのまま前提にすると、対象バージョンでは使えない機能に依存した設計になりかねません。
設計の初期に、対象バージョンで「どの認証サービス種別が使えるか」「必要なグラントが OAuth 2.0 クライアント登録でサポートされているか」「トークンの構成をどこまで細かく制御できるか」を確認し、実際に使える機能の範囲で設計を固めるのが実務の鉄則です。
まとめ
- 認証は用途で分ける。 人の対話ログインは SAML 2.0 / OIDC、サービス間・API は OAuth 2.0。ひとつの認証サービスで兼ねない
- 認証サービスとして外出しするPega の構造を活かし、用途ごとに独立して定義する
- SSO の肝はクレーム→Access Group / Operator のマッピング。Operator を事前登録するか JIT 生成するかを要件で選ぶ
- API 認証で Basic 認証を使い回すのはアンチパターン。OAuth 2.0 に寄せる
- 失敗は 3 つ——トークン失効・リフレッシュの欠如、IdP グループ未マッピングで全員が既定 Access Group に落ちる、SLO の未考慮
- 機能はバージョン差があるため、対象バージョンで使える機能で設計を固める
認証は、動いてしまうと「とりあえず通ったからよし」で流れがちな領域です。しかし用途の分離・マッピング・トークンとログアウトの設計を最初に言語化しておくかどうかで、後工程のセキュリティ事故と手戻りの量が決定的に変わります。
関連リンク
関連記事
Pega 宣言的処理のコスト設計｜前方連鎖と後方連鎖の使い分け
Declare Expression は便利だが、前方連鎖のカスケードは1つのプロパティ変更が広範な再計算を引き起こす。宣言的処理は「書けば動く」半面、実行コストが見えにくい。本記事は前方連鎖と後方連鎖、宣言的と手続き的の境界線を、性能と保守性の観点で整理する。
記事を読むPega Insights と Report Definition の使い分け｜セルフサービス分析と運用レポートの線引き
「レポートは Report Definition で作るべきか、Insights でユーザーに任せるべきか」——ダッシュボード設計で必ず出る分岐です。統制と再利用が要る定型レポートはルール化し、アドホックな探索はセルフサービスに開く、が基本方針。本記事では両者のガバナンス差とデータソースの前提から、線引きの判断軸を示します。
記事を読むPega 監査証跡設計：フィールド監査・履歴・セキュリティ監査の使い分け
「何を、どこまで監査するか」は Pega のセキュリティ設計で最も判断が割れるテーマです。フィールド監査・ケース履歴・セキュリティイベントの使い分けと、監査のかけ過ぎが招く性能・容量問題の回避策を、LSA の視点で解説します。
記事を読む