OAuth 2.0の使用

OAuth 2.0は業界標準の認証プロトコルです。 Liferay ベースの Web サイトにアカウントを持つユーザーは、選択した資格情報をさまざまなクライアントとシームレスに共有できます。 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がそのユーザーとアプリケーションに対して持っているものとトークンが一致すれば、データを取得するためのアクセスが許可されます。

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

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 ロールの場合、仕様で とマークされている要件は (および同等の用語) が実装およびサポートされています。 すべき または してもよい とマークされた要件のサポートは、DXP のバージョンによって異なります。

今後の流れ

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