ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、こちらまでご連絡ください。

OAuth 2.0を使用する

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

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

OAuth 2.0のフロー

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

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

OAuth 2.0はWeb標準を利用しています。

ユーザーは、LiferayベースのWebサイトから認証情報による認証をサポートするサードパーティ製アプリケーションにアクセスします。アプリケーション（Webまたはモバイル）において、ユーザーはOAuthを介して認証を要求し、ブラウザまたはアプリをLiferayベースのWebサイトに送信します。コード交換用証明キー または PKCE フロー (下記参照) を使用する場合、アプリケーションはコード検証ツールも生成し、それに対して変換を適用して作成されたコードチャレンジを送信します。
ユーザーが認証され、アプリケーションがアクセス許可を必要とするリソースが表示されます。ユーザーが許可をクリックして許可を与えると、Liferay は HTTPS 経由でアプリケーションに送信される認証コードを生成しました。
アプリケーションはその後、より永続的なアクセストークンを要求し、要求とともにコードを送信します（ PKCE コード検証ツールも一緒に）。

注記

同じインスタンス上でトークンを要求する場合、Liferayはネットワークトラフィックを発生させません。
認証コードが一致し（かつ変換された PKCE コード検証器が以前に送信されたコードチャレンジと一致する場合）、Liferay はこのユーザーとアプリケーションの組み合わせに対してアクセストークンを暗号化して生成します。 HTTPSを介してアプリケーションにトークンが送信されます。これで初期認証は完了です。
アプリケーションはデータを取得する必要がある場合、そのデータを取得することが許可されていることを証明するリクエストとともにトークンを送信します。
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 のバージョンによって異なります。

仕様	説明	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
リリース機能 LPD-63415 OAuth 2.0 保護されたリソースメタデータ (RFC 9728)	リソースサーバーが /.well-known エンドポイントで信頼する認証サーバーを通知するために使用する標準化されたメタデータドキュメントを定義します。	該当する場合、サポートを提供します。	RFC 9728
JWTベアラートークン認証付与（RFC 7523）	システム統合のためのJWTベースの認証付与を定義します。	該当する場合、サポートを提供します。	RFC 7523
OAuth 2.0アクセストークン用のJWTプロファイル（RFC 9068）	標準的なJWTベースのアクセストークン形式を定義します。	該当する場合、サポートを提供します。	RFC 9068
Liferay DXP 2026.Q3+`<br/> OAuth 2.0 のリソースインジケータ (RFC 8707) \| クライアントがアクセストークンの対象となる保護されたリソースの名前を指定するために送信する`リソースパラメータを定義します。	認証コードおよびクライアント資格情報による権限付与に対応しています。	RFC 8707

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

リリース機能

Liferay DXP 2026.Q1+

重要

現在、この機能はリリース機能フラグ（LPD-63415）によって制限されています。詳細については、リリース機能フラグを参照してください。

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

グローバルメニュー (を開き、 コントロールパネルに移動し、セキュリティの下にある OAuth クライアント管理 をクリックします。
認証サーバーのローカルメタデータ タブを開きます。
OpenID 構成 または OAuth 認証サーバー タブを選択します。どちらのタブも同じメタデータエントリを設定します。 OpenID 設定 タブでは、OpenID Connect 固有のフィールドが追加されます。
新規をクリックしてください。
下記のフォームにご記入ください。
メタデータエントリを有効にするには、 を切り替え、 を有効にします。
をクリックして保存します。

発行者 (必須): 認証サーバーの一意の識別子。これは、トークンを発行する機関を特定するものです。例： 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は読み取り専用であり、各フィールドに入力された値に基づいて自動的に生成されます。

各タブには読み取り専用の 認証サーバーのローカルな既知の URI が表示されます。 Liferay は、 発行者 と トークンエンドポイント の値からそれを生成し、エントリを識別するために使用します。以下の検出エンドポイントからメタデータを取得します。

検出エンドポイント

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

/.well-known/oauth-authorization-server (RFC 8414)

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

OAuth認証サーバー検出

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

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

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

メタデータエントリが存在しない場合、または有効になっていない場合、エンドポイントは 404 を返します。
有効になっているエントリがちょうど1つだけの場合、そのエントリが返されます。
複数のエントリが有効になっている場合、Liferay は最初に作成された有効なエントリを返します。

特定の発行者をリクエストする

RFC 8414で規定されているように、エントリのメタデータに直接アクセスするには、発行者自身のパスを既知のパスに追加します。発行者 が https://example.com/o/oauth2 であるエントリは、メタデータを次の場所に公開します。

https://example.com/.well-known/oauth-authorization-server/o/oauth2

Liferayは、要求されたホストとパスサフィックスから発行者を再構築し、その発行者を持つ有効なエントリを検索します。一致するエントリがない場合、または一致するエントリが無効になっている場合、エンドポイントは 404 を返します。

Liferay はリクエストから発行者を再構築するため、このフォームは 発行者 がリクエストを処理する Liferay インスタンス (インスタンス自身の OAuth 2.0 認証サーバーなど) の名前になっているエントリにのみ到達します。外部認証サーバーを記述するエントリは、上記のベアホストルートエンドポイントでのみ提供され、かつ、最初に作成された有効なエントリである場合に限ります。

保護されたリソースメタデータ（RFC 9728）

リリース機能

Liferay DXP 2026.Q3+

重要

現在、この機能はリリース機能フラグ（LPD-63415）によって制限されています。詳細については、リリース機能フラグを参照してください。

Liferay DXP は RFC 9728 で定義されている OAuth 2.0 保護リソースメタデータをサポートしています。保護されたリソース は、OAuth アクセストークンによってデータが保護されるサーバーであり、ヘッドレス API などが含まれます。このメタデータを公開すると、OAuthクライアントは、クライアントごとの設定なしに、どの認証サーバーがそのリソースのトークンを発行しているかを検出できます。

注記

Liferay の MCP サーバーも保護されたリソースですが、独自のメタデータを /o/.well-known/oauth-protected-resource/mcp に公開します。ここにはその項目を追加しないでください。

エントリを設定するには、

グローバルメニュー (を開き、 コントロールパネルに移動し、セキュリティの下にある OAuth クライアント管理 をクリックします。
保護されたリソースのローカルメタデータ タブを開きます。
新規をクリックしてください。

フォームに記入してください：

分野	説明
リソース (必須)	保護されたリソースを識別するHTTPS URL。 Liferayは、保存する前に、それが正しい形式のHTTPS URLであることを検証し、重複するリソースを拒否します。例： `https://example.com/o/headless-delivery`
リソース名	リソースの人間が読みやすい名前。
認証サーバー (必須)	このリソースのトークンを発行する可能性のある認証サーバー発行者のURLをカンマ区切りで指定したリスト。各認証サーバーの認証サーバーメタデータエントリの発行者フィールドと同じ値を使用します。例： `https://auth.mycompany.com/o/oauth2`
サポートされているベアラ方式	クライアントがこのリソースに対してベアラートークンを提示するために使用するメソッドの、コンマ区切りのリスト。例：`ヘッダー`、`ボディ`、`クエリ`など（RFC 6750を参照）。デフォルトは `ヘッダー` です。
サポートされているスコープ	リソースサーバーがサポートするスコープをカンマ区切りで指定したリスト。
有効にする	メタデータエントリを有効にします。有効化されたエントリのみが、周知のURIに公開されます。

Liferay は、入力から生成した 2 つの読み取り専用フィールドも表示します。 保護されたリソースのローカルウェルカウン URI (このエントリのメタデータが公開されているウェルカウン URI。リソース URL から派生) と 保護されたリソースのメタデータ JSON (その URI で公開されているメタデータドキュメント)。

をクリックして保存します。

エントリを保存すると、そのエントリは 保護されたリソースのローカルメタデータ リストに、そのリソースと既知の URI とともに表示されます。よく知られているURIにアクセスして、LiferayがメタデータJSONドキュメントを返すことを確認してください。

行の アクション メニュー () を開いて、そのエントリを編集または削除します。また、リスト内のエントリをクリックして開くこともできます。複数のエントリを一度に削除するには、該当する行を選択して、管理ツールバーの削除をクリックします。 Liferayがエントリを削除する前に、確認モーダルが表示されます。

検出エンドポイント

Liferay は、リソースのホストとパスの間に /.well-known/oauth-protected-resource を挿入することにより、各エントリの保護されたリソースのローカル Well-Known URI を生成します。例えば、リソース https://example.com/o/headless-delivery は、メタデータを https://example.com/.well-known/oauth-protected-resource/o/headless-delivery に公開します。したがって、同一インスタンス上の各リソースは、それぞれ固有の既知のURIでメタデータを公開します。エントリ固有の既知のURIをリクエストすることで、そのメタデータに直接アクセスできます。

ホストルートにある /.well-known/oauth-protected-resource も機能し、パスのないリソース (たとえば、 https://example.com ) をカバーします。メタデータエントリが存在しない場合、または有効になっていない場合、これらのURIのいずれかは 404を返します。

注記

複数のエントリが有効になっている場合に、ホストルートURIのみを要求すると、実際に必要なリソースに関係なく、最初に作成されたエントリのみが返されます。特定のリソースのメタデータに確実にアクセスするには、そのリソースの既知のURIをリクエストしてください。

エンドポイントは、有効になっているメタデータエントリと、UI で設定されているフィールド ( resource、 authorization_servers、 bearer_methods_supported、および resource_name を含む) から生成された JSON ドキュメントを返します。サポートされるスコープを設定した場合のみ、 scopes_supported が含まれます。

リソースインジケータ（RFC 8707）

Liferay DXP 2026.Q3+

Liferay DXP は RFC 8707 で定義されている OAuth 2.0 のリソースインジケータをサポートしています。クライアントは、1 つ以上の リソース パラメータをトークンエンドポイントに送信することにより、1 つ以上の保護されたリソースのトークンを要求します。 Liferayはこれらの値をトークンのオーディエンスとして記録し、リソースサーバーはそれらを読み取り、そのトークンに対して発行されていないトークンを拒否します。

リソース指標はすぐに使用できます。支援は助成金によって異なります。

助成金の種類	栄誉 `リソース`
認証コード	はい
クライアント認証情報	はい
JWTベアラー	いいえ
リフレッシュトークン	いいえ
リソース所有者のパスワード	いいえ

リソース を尊重しないグラントは、リクエストを拒否するのではなく、パラメーターを無視します。

各 リソース の値は、フラグメントを含まない絶対 URI である必要があります。複数のオーディエンスを要求する場合は、パラメータを繰り返してください。値が空白、相対値、またはフラグメントを含む場合、トークンエンドポイントは 400 をエラーコード invalid_target とともに応答し、トークンを発行しません。

Liferayは、検証済みの値を認証レコードとともに保存します。

トークンイントロスペクションエンドポイントは、トークンのオーディエンスをその aud メンバーに報告します。トークンに 1 つ以上のオーディエンスがある場合、オーディエンスの数に関係なく、 aud は常に文字列の JSON 配列になります。トークンがない場合、レスポンスでは aud が省略されます。

Liferay の MCP サーバーは、この動作を最も明確に利用している例です。つまり、リソース URI を含むオーディエンスを持つトークンのみを受け入れます。有効なトークンを取得するには、トークンを要求する際に、そのURIを リソース パラメータとして送信します。

機能の利用可能性

特徴	ベータ版として利用可能	リリースとして入手可能	一般的に入手可能
OAuth 2.0 動的クライアント登録 (RFC 7591)	Liferay DXP 2026.Q1 LTS (LPD-63416)	Liferay DXP 2026.Q3 (LPD-63416)	-
OAuth 2.0 認証サーバーメタデータ (RFC 8414)	Liferay DXP 2026.Q1 LTS (LPD-63415)	Liferay DXP 2026.Q3 (LPD-63415)	-
OAuth 2.0 保護されたリソースメタデータ (RFC 9728)	-	Liferay DXP 2026.Q3 (LPD-63415)	-