OAuth 2.0の使用

OAuth 2.0は業界標準の認証プロトコルです。 Liferayベースのウェブサイトにアカウントを持つユーザーは、選択した認証情報をさまざまなクライアントとシームレスに共有できます。 OAuth 2.0は、ユーザーが所有するリソース（メールアドレス、ユーザープロフィール画像、またはアカウント関連のもの）やその他の許可されたリソースの一部に対して、パスワードなしでアクセスすることを許可します。 OAuth 2.0の設計はHTTPSを介してすべての認証トランスポートを暗号化し、システム間で渡されるデータが傍受されるのを防ぎます。

OAuth 2.0アプリの作成に進むか、引き続き読み進め、その仕組みを学習できます。

1. OAuth 2.0アプリケーションの作成
2. スコープの定義
3. アカウントアクセスの承認

OAuth 2.0のフロー

OAuth 2.0は可能な限りWeb標準を利用します。トランスポートはHTTPSで暗号化されます。トークンはHTTPヘッダーとして実装されます。データはWebサービスを介して渡されます。

OAuth 2.0の仕組みは次のとおりです。

1. ユーザーは、LiferayベースのWebサイトからの認証情報を介した認証をサポートするサードパーティのアプリケーションにアクセスします。 アプリケーション（Webまたはモバイル）で、ユーザーはOAuthを介して認証をリクエストし、ブラウザまたはアプリをLiferayベースのWebサイトに送信します。 コード交換用証明キー または PKCE フロー (下記参照) を使用する場合、アプリケーションはコード検証ツールも生成し、それに対して変換を適用して作成されたコードチャレンジを送信します。

2. ユーザーが認証され、アプリケーションがアクセス許可を必要とするリソースが表示されます。 ユーザーが［許可］をクリックして許可すると、LiferayはHTTPS経由でアプリケーションに送信される認証コードを生成します。

3. アプリケーションはその後、より永続的なアクセストークンを要求し、要求とともにコードを送信します（ PKCE コード検証ツールも一緒に）。

   注

   同じインスタンス上でトークンを要求する場合、Liferayはネットワークトラフィックを発生させません。

4. 認証コードが一致し（かつ変換された PKCE コード検証が以前に送信されたコードチャレンジと一致する場合）、Liferay はこのユーザーとアプリケーションの組み合わせに対してアクセス トークンを暗号化して生成します。 HTTPSを介してアプリケーションにトークンが送信されます。 これで初期認証は完了です。

5. アプリケーションはデータを取得する必要がある場合、そのデータを取得することが許可されていることを証明するリクエストとともにトークンを送信します。

6. Liferayがそのユーザーとアプリケーションに対して持っているものとトークンが一致すれば、データを取得するためのアクセスが許可されます。

その説明には多くの用語が含まれています。 以下に定義を示します。

重要

ユーザーがアクセストークンを生成および表示するには、以下の2つの権限が必要です。

• コントロールパネル → セキュリティ → OAuth 2 管理 - OAuth 2 アプリケーションエントリ → トークンの作成
• コントロールパネル → セキュリティ → OAuth 2 管理 - OAuth 2 アプリケーションエントリ → 表示

OAuth 2.0の用語

認証：認証情報を提供して、システムがそれらの認証情報と保存されているものとを照合することにより、ユーザーが誰であるかを確認できるようにすること。 OAuthは認証プロトコルではありません。

承認：別のシステムに格納されているリソースへのアクセス権の付与。 OAuthは承認プロトコルです。

アプリケーション：リソースへのアクセスが許可される必要があるクライアント（Web、モバイルなど）。 ユーザーがリソースへのアクセスを承認するには、管理者がアプリケーションを登録する必要があります。

クライアント： アプリケーション とほぼ同義。ただし、アプリケーションにはWebやモバイルなどのバリアントがあります。 これらのバリアントがクライアントです。

クライアントID：認識できるようにクライアントに与えられる識別子。

クライアントシークレット：クライアントを正当なクライアントとして識別する、あらかじめ合意されたテキスト文字列。

アクセストークン：そのユーザーのリソースにアクセスするためのユーザーとクライアントの組み合わせを識別する、暗号化して生成されたテキスト文字列。

レスポンスタイプ: OAuth 2.0 は複数のレスポンスタイプをサポートしています。 上の図で説明されているのは、最も一般的な認証コードです。 他の応答タイプは、パスワード（ユーザー名とパスワードによるログイン）とクライアント認証情報（事前定義されたヘッドレスアプリケーションアクセス）です。

スコープ：アプリケーションがアクセスを希望する対象を定義する項目のリスト。 このリストは、最初の承認リクエスト中に送信される（または、アプリケーション登録で選択されたスコープがデフォルトで設定される）ため、ユーザーはリソースへのアクセスを許可または拒否できます。

コールバック URI: リダイレクト エンドポイント URI とも呼ばれます。 承認が完了すると、承認サーバー（Liferay）がクライアントをこの場所に送信します。

技術規格および仕様

Liferay DXPは、OAuth 2.0仕様で定義されているとおり、認証サーバーとリソースサーバーの役割においてOAuth 2.0を実装しています。 本項のコンプライアンスに関する記述は、これらの役割にのみ適用されます。

Liferay は、相互運用性を促進し、ベンダーロックインを減らすために OAuth ワーキンググループ が公開した仕様を実装しています。 特定のDXPバージョンにはベンダー固有の拡張機能が存在する場合がありますが、LiferayはLiferay DXP自体をカスタマイズするのではなく、外部ソリューションを通じてこれらの要件に対応しています。 これらの仕様を拡張または改変する機能は、正式なOAuth 2.0準拠の主張の範囲外となります。

以下の仕様では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、 RFC 2119 に記載されているとおりに解釈されます。

Liferay DXP によって実装される OAuth 2.0 ロールについては、仕様書で MUST (および同等の用語) とマークされた要件が実装され、サポートされます。 SHOULD または MAY とマークされた要件のサポートは、DXP のバージョンによって異なります。

仕様	Description	Liferay DXPに実装されています	リンク
OAuth 2.0認証フレームワーク（RFC 6749）	OAuthの役割、認証フロー、トークン、およびスコープを定義します。	サポートされている役割のすべての 必須 要件が実装されています。	RFC 6749
コード交換のための証明鍵（PKCE、RFC 7636）	認証コードフローに対する傍受攻撃からの保護策を定義します。	認証コードフローに対応しています。	RFC 7636
ベアラートークンの使用方法（RFC 6750）	ベアラートークンを使用して保護されたリソースにアクセスする方法を指定します。	すべての 必須 要件が実装されています。	RFC 6750
OAuth 2.0 トークンイントロスペクション (RFC 7662)	リソースサーバーがトークンの状態を照会するためのメカニズムを定義します。	該当する場合、サポートを提供します。	RFC 7662
OAuth 2.0の脅威モデルとセキュリティに関する考慮事項（RFC 6819）	セキュリティ上の脅威と推奨される対策を明記します。	セキュリティに関する推奨事項は、該当する場合に適用されます。	RFC 6819
ベータ版機能 LPD-63416 OAuth 2.0 動的クライアント登録プロトコル (RFC 7591)	クライアントが認証サーバーに動的に登録するための標準的な方法を定義します。	該当する場合、サポートを提供します。	RFC 7591
ベータ版機能 LPD-63415 OAuth 2.0 認証サーバーメタデータ (RFC 8414)	/.well-known エンドポイントで認証サーバーの機能を公開する標準化されたメタデータ文書を定義します。	該当する場合、サポートを提供します。	RFC 8414
JWTベアラートークン認証付与（RFC 7523）	システム統合のためのJWTベースの認証付与を定義します。	該当する場合、サポートを提供します。	RFC 7523
OAuth 2.0アクセストークン用のJWTプロファイル（RFC 9068）	標準的なJWTベースのアクセストークン形式を定義します。	該当する場合、サポートを提供します。	RFC 9068

認証サーバーメタデータ（RFC 8414）

ベータ機能

Liferay DXP 2026.Q1+

重要

現在、この機能はベータ版機能フラグ（LPD-63415）によって制限されています。 詳細については、 ベータ版機能フラグ をお読みください。

Liferay DXP は RFC 8414 で定義されている OAuth 2.0 認証サーバーメタデータをサポートしています。 設定するには、

1. グローバルメニュー (を開き、 コントロールパネルに移動し、セキュリティの下にある OAuth クライアント管理 をクリックします。

2. 認証サーバーローカルメタデータ タブを開きます。

3. OpenID 構成 または OAuth 認証サーバー タブを選択します。 どちらのタブも同じメタデータエントリを設定します。 違いは、公開されている よく知られている URI と、OpenID タブで使用できる OpenID Connect 固有のフィールドです。

4. ［新規］をクリックします。

5. フォームに記入します（以下を参照）。

6. トグル を有効にして を有効にすると、メタデータエントリがアクティブになります。

7. ［Save（保存）］をクリックします。

発行者 (必須): 認証サーバーの一意の識別子。 これは、トークンを発行する機関を特定するものです。 例： https://auth.mycompany.com/o/oauth2

サポートされているスコープ: 認証サーバーによってサポートされ、メタデータ ドキュメントに公開されているスコープ。

サポートされているグラントタイプ: 認証サーバーでサポートされている OAuth 2.0 グラントタイプ (例: authorization_code、 client_credentials)。

認証エンドポイント: 認証リクエストが送信され、ユーザーが同意を与える HTTPS URL。 例： https://auth.mycompany.com/o/oauth2/authorize

JWKS URI: 認証サーバーが公開署名キーを公開する HTTPS URL。 例： https://auth.mycompany.com/o/oauth2/jwks

トークンエンドポイント: クライアントが認証コードまたは資格情報をアクセストークンと交換する HTTPS エンドポイント。 例： https://auth.mycompany.com/o/oauth2/token

有効化 (OAuth): メタデータエントリをアクティブとしてマークします。 検出エンドポイントからは、有効なエントリのみが返されます。 無効化されたエントリは、発行者がリクエストと一致していても無視されます。

登録エンドポイント (OAuth): サポートされている場合、動的なクライアント登録に使用される HTTPS エンドポイント。 例： https://auth.mycompany.com/o/oauth2/registration

サポートされているサブジェクトタイプ (OpenID): クライアントに対してユーザーを識別する方法を記述する JSON 配列。 少なくとも 1 つの値を含み、 public を含める必要があります。 例: ["public", "pairwise"]

UserInfo エンドポイント (OpenID): OpenID Connect を使用する際にクライアントが認証済みユーザークレームを取得する HTTPS エンドポイント。 例： https://auth.mycompany.com/o/oauth2/userinfo

注

UIに表示されるメタデータJSONは読み取り専用であり、各フィールドに入力された値に基づいて自動的に生成されます。

検出エンドポイント

少なくとも1つのメタデータエントリが有効になっている場合、Liferayは以下の既知のエンドポイントを公開します。

• /o/.well-known/oauth-authorization-server (RFC 8414)
• /o/.well-known/openid-configuration (OpenID Connect)

各エンドポイントは、有効化されたメタデータエントリとUIで設定されたフィールドから生成されたJSONドキュメントを返します。

OAuth認証サーバー検出

/o/.well-known/oauth-authorization-server は、OAuth 2.0 メタデータを返します。

• issuer
• authorization_endpoint
• token_endpoint
• jwks_uri
• 支援対象となる助成金の種類
• サポートされているスコープ

OpenID Connect固有のフィールド（例えば、 userinfo_endpoint および subject_types_supported）は、OpenID Connect検出エンドポイントにのみ含まれます。

返されるメタデータに加えて、エンドポイントは以下の応答動作に従います。

• メタデータエントリが存在しない場合、または有効になっていない場合、エンドポイントは 404 を返します。

• 有効になっているエントリがちょうど1つだけの場合、そのエントリが返されます。

• 複数のエントリが有効になっている場合、Liferay は最初に作成された有効なエントリを返します。

リクエストに 発行者 クエリ パラメータが含まれている場合、Liferay はそれを有効なエントリと照合しようとします。

• 一致するエントリが見つかり、かつ有効になっている場合は、それが返されます。
• 一致するエントリが見つかったが無効になっている場合、エンドポイントは 404 を返します。
• 一致するエントリが見つからない場合、エンドポイントは 404 を返します。

OpenID Connect Discovery

/o/.well-known/openid-configuration は OpenID Connect メタデータを返します。 OAuthフィールドに加えて、

• userinfo_endpoint
• subject_types_supported
• サポートされている応答タイプ
• サポートされている署名アルゴリズム

今後の流れ

• OAuth2アプリケーションの作成
• OAuth2によるアカウントアクセスの承認
• OAuth 2.0のスコープ
• OAuth2によるユーザーの認証