OpenID Connect (OIDC)
OpenID Connect (OIDC)（オープンアイディー・コネクト）は、OAuth 2.0 の上に構築された「認証」の標準です。
OAuth 2.0 を使うと、「アクセストークンを用いて保護されたリソースサーバーのデータにアクセスする」ことができましたが、「ユーザーが誰か」を伝える仕組みはありませんでした。（認可のためのフレームワークなので当たり前ですね）
OIDC は OAuth 2.0 を拡張し、OAuth 2.0 の認可機能に加えて、ユーザーの情報を標準的な形式で伝えられるようにした認証機構です。
OIDC を使用すると SSO を実現することができます。
SSO を実現する色々な方法
SSO を実現する方法には、「フェデレーション」「リバースプロキシ」「エージェント」「クライアント代行」の4つがあり、OIDC はフェデレーション方式の一つです。
フェデレーション方式での SSO には、OIDC の他にも SAML (Security Assertion Markup Language) を使った方法がありますが、どちらにせよ基盤実装のコストが高い特徴があります。
また、旧版の Nogiku（MF98/KF76 で使用）では、一部システムでリバースプロキシ方式による SSO が使用されていました。この方式では、クライアントアプリ上でユーザーが ID とパスワードを入力し、クライアントアプリがこの通信を Nogiku へとプロキシします。
OAuth 2.0 から OIDC へ
OIDC では、Authorization Code Flow など OAuth 2.0 の認可フローをそのまま土台にしつつ、次の要素を追加します。
| 追加要素 | 役割 |
|---|---|
openid スコープ | 「認証を行う」ことを認可サーバーに伝える合図 |
| ID Token | 「このユーザーは誰か」を示す JWT（署名付きトークン） |
| UserInfo エンドポイント | アクセストークンを提示して、追加のユーザー情報を取得する API |
| Discovery メタデータ | 各エンドポイントの URL 等の情報を標準形式で公開する仕組み |
つまり、OIDC は OAuth 2.0 の上に「認証レイヤー」を載せたものと考えると分かりやすいです。認可と認証が一つのフローでまとめて扱えるようになります。
RFC 技術仕様
OIDC の仕様は OpenID Connect Core 1.0 に定義されています。OAuth 2.0（RFC 6749）が前提となっています。
OIDC の登場人物
OAuth 2.0 と OpenID Connect では、使われる用語が少し変化している場合があります。
認証の文脈が加わっているので全く同じ単語にはならないわけですね。言葉で混乱しないように注意して押さえておきましょう。
| 用語 | 役割 | OAuth 2.0 との対応 |
|---|---|---|
| OpenID Provider（IdP / OP） | ユーザーを認証し、ID Token を発行するサーバー | OAuth における認可サーバー（Authorization Server） |
| Relying Party（RP） | IdP の認証結果を信頼してログイン処理を行うアプリケーション | OAuth におけるクライアント（Client） |
| エンドユーザー（End-User） | サインインする本人 | OAuth におけるリソースオーナー（Resource Owner） |
openid スコープ
OIDC の認可リクエストでは、スコープに openid を含める必要があります。これは「認可だけでなく認証も行ってほしい」という合図です。
openid が含まれていないリクエストは、純粋な OAuth 2.0 の認可リクエストとして扱われ、ID Token は発行されません。
例えば、Nogiku が標準でサポートするスコープは次の通りです。
| スコープ | 意味 |
|---|---|
openid | 認証（OIDC 利用時は必須） |
profile | 氏名などプロフィール情報の読み取り |
email | メールアドレスの読み取り |
offline_access | リフレッシュトークンの発行（長期間のセッション維持） |
ID Token
ID Token は、OIDC が OAuth 2.0 に追加した中核の仕組みです。「IdP がこのユーザーを認証した」という結果 を、署名付き JWT としてクライアントに渡します。
前章で紹介した JWT と同様、ID Token も改ざん検知用の電子署名を含みます。RP は IdP の公開鍵で署名を検証し、内容を信頼できるか判断します。
ID Token に含まれる代表的なクレーム（claim）は次のとおりです。
| クレーム | 意味 |
|---|---|
sub | ユーザーを一意に識別する ID（Subject） |
iss | ID Token を発行した IdP の識別子（Issuer） |
aud | このトークンの宛先（通常は client_id） |
exp | 有効期限（Unix 時刻） |
iat | 発行時刻 |
nonce | リプレイ攻撃対策用の値（5 章で説明） |
sub クレーム
sub クレームには、大抵の場合 IdP におけるユーザーの ID が入っています。 Nogiku Auth の場合、sub クレームには User.id が格納されます。
アクセストークンとの違い
トークン取得フェーズでは、ID Token に加えて OAuth 従来のアクセストークンも一緒に返却されます。
端的に言えば ID Token が「認証トークン」、アクセストークンが「認可トークン」ですあり、それぞれ使われ方が異なります。
| ID Token | アクセストークン | |
|---|---|---|
| 目的 | 「誰がログインしたか」を伝える（認証） | 保護されたリソースへアクセスする権限を示す（認可） |
| 主な利用者 | RP（ログイン処理を行うクライアント） | リソースサーバー（保護された API） |
| 典型的な使い方 | 署名検証後、sub でユーザーを特定しセッションを確立 | Authorization: Bearer ヘッダーで API を呼ぶ |
RP がログイン処理を行うときは ID Token を使い、保護された API を呼ぶときはアクセストークンを使います。
UserInfo エンドポイント
ID Token だけでも sub など最低限のユーザー識別はできますが、氏名やメールアドレスなど追加の属性が必要な場合があります。
そのとき RP は、UserInfo エンドポイント にアクセストークンを添えてリクエストを送り、ユーザー属性を取得します。返却される内容は、認可リクエストで要求したスコープ（profile, email など）に応じて決まります。
Nogiku では、UserInfo レスポンスに委員会運用向けの追加クレーム（共通 ID、権限情報など）が含まれる場合があります。具体的なフィールドは実装を参照してください。
Discovery（メタデータ）
OIDC では、IdP が各エンドポイントの URL やサポートする機能を Discovery メタデータ として公開します。RP はこのメタデータを読み取ることで、手作業でエンドポイント URL を設定しなくても連携を開始できます。
代表的なエンドポイントは次のとおりです。
| パス | 内容 |
|---|---|
/.well-known/openid-configuration | 認可・トークン・UserInfo 等の URL、サポートするスコープやレスポンスタイプ |
/.well-known/jwks.json | ID Token や JWT 形式アクセストークンの署名検証に使う公開鍵 |
例えば、Nogiku Auth の Discovery URL は次のとおりです。
https://nogiku-auth.komabasai.net/api/.well-known/openid-configurationRP 実装では、まずこの URL からメタデータを取得し、記載されている各エンドポイントへアクセスするのが一般的です。多くのライブラリはこの Discovery を自動的に行います。
OIDC による SSO の流れ
ここまでの要素を、前章の Authorization Code Flow に重ね合わせると、Nogiku SSO の全体像が見えてきます。
このフローにおいて注目すべきは以下の3点です。
- ユーザーは IdP 上でログインを行っていること
- RP は ID Token によって「誰がログインしたか」を把握すること（RP は独自のパスワード認証機構を持っていません）
- リソースサーバーから情報を得るのには OAuth 同様にアクセストークンを使っていること
以上の仕組みにより、委員会で使用される複数システムがそれぞれ RP として登録されていれば、委員ユーザーは Nogiku のアカウント1つで各システムにサインインできます。これが SSO です。
Nogiku Access API の位置づけ
Nogiku Access API (apps/access-engine の /api) はリソースサーバーの一つです。Nogiku Auth の ID Token 及び Userinfo エンドポイントから得られる情報は「その人のプロフィール」のみなので、役職ツリーやユーザーグループ、他のユーザーの情報を取得するには、Nogiku Access API にリソースアクセスを要求する必要があります。
このあと学ぶこと
ここまで、OAuth 及び OIDC の基本的なフローについて学びました。しかし、実運用ではこのフローが悪意のある第三者によって侵害されないよう、複数の防御措置を講じており、これらは RFC 技術仕様によっても OAuth / OIDC の要件として定められています。
続く5章では、OAuth / OIDC 認可・認証フローでセッションが確立されるまでのフローの防御について扱います。ここまで終わると、一通りの OAuth / OIDC （うち、Authorization Code Flow）仕様を押さえたことになります。
また6章では、このフローによって取得した各種トークンの悪用を防ぐための防御について扱います。