構成を選ぶ

多くの OP は 7 つの配備の形のどれかに当てはまります。質問に答えて 1 つに絞り込むか、カードを見比べて自分の配備に合う形を探し、そのカードにあるガイドを読んでください。カードの各項目は、その形に必要な選択肢で、ライブラリが許す唯一の選択ではありません。

構成の絞り込みステップ 1

エンドユーザはサインインしますか？

01ガイド →

ファーストパーティ Web SSO

クライアント種別（seed）: サーバサイドのアプリなら op.ConfidentialClient、または op.PublicClient
プロファイル: profile.OAuth21（既定）
同意: WithFirstPartyClients に挙げたクライアントは省略
送信者制約: なし
subject 種別: public
既定のテーブル以外: なし
サンプル: 40-first-party-skip-consent

02ガイド →

B2B SaaS で、テナントが 1 つの OP の RP である場合

クライアント種別（seed）: テナントごとに SubjectType: "pairwise" を指定した op.ConfidentialClient。テナントは動的登録で追加
プロファイル: profile.OAuth21
同意: 表示。動的登録したクライアントはファーストパーティにできない
送信者制約: なし
subject 種別: pairwise（WithPairwiseSubject(salt)）
既定のテーブル以外: テナントを動的登録するなら oidc_initial_access_tokens と oidc_registration_access_tokens
サンプル: 34-pairwise-saas、41-dynamic-registration

03ガイド →

テナントがユーザと issuer を自分で持つマルチテナント

クライアント種別（seed）: そのテナントの provider に、テナント固有の seed
プロファイル: profile.OAuth21
同意: 表示
送信者制約: なし
subject 種別: public
既定のテーブル以外: テナントごとにテーブル一式（oidcsql.WithTablePrefix）、またはテナントごとのデータベース
サンプル: なし。issuer ごとに op.Provider を 1 つ立てます。テナントがユーザを持つ場合を参照

04ガイド →

モバイル・ネイティブアプリ

クライアント種別（seed）: ApplicationType: "native" を指定した op.PublicClient
プロファイル: profile.OAuth21
同意: 表示
送信者制約: なし。DPoP は任意で、public クライアントのリフレッシュ連鎖を結び付ける
subject 種別: public
既定のテーブル以外: なし
サンプル: 38-native-app。PKCE を使う public クライアントと、loopback 127.0.0.1 の redirect

05ガイド →

SPA

クライアント種別（seed）: op.PublicClient
プロファイル: profile.OAuth21
同意: 表示
送信者制約: なし。DPoP は任意
subject 種別: public
既定のテーブル以外: なし
サンプル: 14-cors-spa。ログイン画面を SPA にする場合は 10-react-login

06ガイド →

マシン間通信

クライアント種別（seed）: op.ConfidentialClient、または op.PrivateKeyJWTClient
プロファイル: profile.OAuth21 と WithGrants(grant.ClientCredentials)。WithGrants は既定の grant 集合を置き換えるため、ブラウザログインも使うなら grant.AuthorizationCode（と grant.RefreshToken）も列挙する
同意: なし。ユーザが関与しない
送信者制約: なし。DPoP または mTLS は任意
subject 種別: 該当なし
既定のテーブル以外: なし。ブラウザログインだけが使う 4 つのテーブルは空のまま
サンプル: 05-client-credentials

07ガイド →

FAPI 2.0、オープンバンキング

クライアント種別（seed）: op.PrivateKeyJWTClient。feature.MTLS があれば op.TLSClientAuthClient や op.SelfSignedTLSClientAuthClient も
プロファイル: profile.FAPI2Baseline、または profile.FAPI2MessageSigning（ガイド）
同意: 表示。WithFirstPartyClients は拒否される
送信者制約: DPoP（プロファイルが有効化）または mTLS（feature.MTLS）
subject 種別: public
既定のテーブル以外: oidc_par_records
サンプル: 03-fapi2、50-fapi-tls-jwks、51-dpop-nonce

既定のテーブルとは、パスワードログインを使う認可コードフローの OP が読む 13 個のテーブルです。一覧とオプションごとに増えるテーブルは TABLES.md にあります。どの形を選んでも migration ファイルはすべて適用してください。構成のどの機能も書き込まないテーブルは、空のままです。同梱の oidc_users テーブルが必要なのは、アダプタ自身のユーザストアを渡す場合だけです。自前の users テーブルを使う一般的な構成（既存のデータベースに組み込む）では要りません。

カードの項目の読み方

クライアント種別 は op.WithStaticClients に渡すシードです。シードが token endpoint の認証方式を決めます。op.PublicClient は PKCE を伴う none、op.ConfidentialClient はクライアントシークレット、秘密鍵と証明書のシードは非対称方式です。動的登録や管理 API でも、実行時に同じ種類のクライアントを作れます（クライアントオンボーディングのパターン）。
プロファイル は OP に 1 つで、クライアントごとではありません。profile.OAuth21 は op.WithProfile を指定しない OP の既定で、要求するのは PKCE だけです。FAPI プロファイルはすべてのクライアントの認証を非対称方式に絞るため、public クライアントや共有シークレットのクライアントとは同じ OP に同居できません。SPA と FAPI の API は別々の OP として動かすか、FAPI プロファイルを使わない構成にします。
同意は、静的クライアントが op.WithFirstPartyClients に挙がっていなければ表示されます。この一覧に指定できるのは静的シードで登録したクライアントだけで、FAPI 2.0 プロファイルとは併用できず拒否されます。
送信者制約 はトークンを鍵または証明書に結び付けます。FAPI プロファイルは必須とし、ほかの形は feature.DPoP か feature.MTLS を有効にしない限り bearer トークンで動きます。2 つの比較は送信者制約にあります。
subject 種別 は、op.WithPairwiseSubject を設定し、クライアントが pairwise を求めたときだけ pairwise になり、それ以外は public です。grant ができた後でモードは変えられないため、公開前に決めてください。

形を混在させる

profile.OAuth21 の下では、1 つの OP が複数のクライアント種別を同時に扱えます。ファーストパーティの Web アプリ、SPA、ネイティブアプリ、マシンクライアントはシードだけが違います。OP 全体で決める設定は、プロファイルと grant の集合です。op.WithGrants は既定の grant 集合を置き換えるため、ブラウザログインとマシンクライアントの両方を持つ OP では、grant.AuthorizationCode、grant.RefreshToken、grant.ClientCredentials をすべて列挙します。

テナントがユーザを持つ場合

OP の issuer は 1 つだけです。op.WithIssuer は単一値で、issuer はすべてのトークンの iss であり、discovery 文書の起点でもあります。テナントごとにユーザを持ち、テナントごとに別の issuer にしたい場合は、テナントごとに op.Provider を 1 つ立てます。それぞれに専用のストアを渡すか、共有データベース上で oidcsql.WithTablePrefix によりテーブル名の prefix を分け、issuer のパス（https://login.example.com/tenant-a、https://login.example.com/tenant-b）の下にマウントします。サブパス形式と 2 つの discovery の位置は Issuer にあります。上の B2B SaaS のカードは、テナントが 1 つの OP の RP で、sub だけを分ける構成であり、ここで述べる構成とは別です。

次に読む

ここから始める — 目的からページを選びます。
必須オプション — op.New が起動を拒否する条件です。
セキュリティプロファイルの宣言 — プロファイルの比較です。

構成を選ぶ ​