Documentation

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:OAuth 2.0はWeb標準を利用しています。

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

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

  3. 次に、アプリケーションは、より永続的な認証トークンを要求し、その要求と共に(PKCE コード検証機能と共に)コードを送信します。

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

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

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

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

OAuth 2.0の用語

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

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

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

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

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

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

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

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

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

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

OAuth 2.0の設定を開始する準備はできましたか? 次のステップは、アプリケーションの作成です。