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

OAuth2によるアカウントアクセスの承認

アプリケーションを登録したら、ユーザーの承認を開始できます。そのためには、認可サーバー (Liferay DXP) への URL を構築する必要があります。認可サーバーは、前のチュートリアルでスコープとして定義されたリソースに対する要求された権限を認可するようにユーザーに求めます。

認証コードのフロー

最も一般的な OAuth フローは、Web アプリケーションに使用される認証コードフローです。このための URL には、次のリクエストパラメータが必要です。

response_type
client_id

この承認の URL を構築するには、次のパターンに従います。

https://[hostname]/o/oauth2/authorize?response_type=code&client_id=[client ID]

クライアント ID はアプリケーションの登録から取得されます。自動的に生成されます（アプリケーションを編集すると変更できます）。

ユーザーがリソースへの要求されたアクセス許可を承認すると、承認サーバーは、登録されたコールバックURI（別名リダイレクトURI）でアプリケーションに認証コードをクエリ文字列パラメーターとして返します。

[your callback URI]?code=[authorization server generated code]

アプリケーションは、次のパターンに従って POST リクエストを送信し、この認証コードをアクセストークンと交換する必要があります。

http://localhost:8080/o/oauth2/token

重要

「Web アプリケーション」という語句は、上記の URL が Web ブラウザから直接要求されるアプリケーションを意味するという意味で、あいまいに使用されることがあります。このような事態が発生すると、クライアントシークレットが漏洩し、許可フローとアプリケーションのセキュリティが侵害されることになります。このような場合は、アプリケーションを登録するときに、代わりに ユーザーエージェントアプリケーション クライアントプロファイルを選択してください。これにより、アプリケーションで安全な代替手段である PKCE 拡張認証コードフローが利用できるようになります (以下を参照)。

リクエストがボディに以下のパラメータ（ application/x-www-form-urlencodedとしてエンコード）とともに送信された場合…

client_id=[client ID] client_secret=[client secret] grant_type=authorization_code code=[authorization server generated code] redirect_uri=[registered callback URI]

…HTTP 応答の本文には次のような JSON が含まれます。

{
  "access_token": "[authorization server generated access token]",
  "token_type": "Bearer",
  "expires_in": 600,
  "scope": "[the scopes that were authorized by the user]",
  "refresh_token": "[authorization server generated refresh token]"
}

これからアクセストークンを抽出して保存する必要があります。トークンを無期限に使用する場合 (上記の例の 600 秒を超える場合)、リフレッシュトークンも必要になります。これをリフレッシュトークンフローと組み合わせて使用すると、追加のユーザー認証なしで、同じ権限を持つ新しいアクセストークンを取得できます。アプリケーション登録がこのフローに登録されている場合にのみ、認可サーバーはリフレッシュトークンを発行します。

重要

標準ユーザーはアクセストークンを作成できません。次の権限を持つカスタム OAuth 2 管理者ロールを使用します。

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

PKCE拡張認証コードフロー

このフローは、コード交換用の証明キー (PKCE) を追加した上記と同じです。別のリクエストパラメータが必要です: code_challenge。このフローは、ユーザー認証後に認証サーバーによってリダイレクトされる URL (およびリクエストパラメーター) に単独でアクセスできない可能性があるスマートフォンアプリケーションなどのクライアント用です。応答コードを読み取って、同じシステム上の悪意のあるアプリケーションが自身を認証するのを防ぎます。これを行うには、クライアントアプリケーションは、生成した自分自身だけが知っている文字列である認証要求とともに コードチャレンジ を送信します。この文字列を生成するには、まず コード検証と呼ばれる別の秘密の文字列を作成し、それに変換を適用する必要があります。承認後、承認コードとともにコード検証が送信され、クライアントが検証されます。

これを行う方法の詳細については、 PKCE 仕様を参照してください。

このフローをサポートするには、アプリケーションの作成時に、許可された認証タイプとして PKCE を定義しておく必要があります。これは、ネイティブアプリケーションおよびユーザーエージェントアプリケーションクライアントプロファイルの一部です。 PKCE を使用して認証コードを要求するには、 code_challenge 要求パラメータを含む URL を使用します。

https://[hostname]/o/oauth2/authorize?response_type=code&client_id=[client ID]&code_challenge=[PKCE code challenge]

残りのプロセスは承認コードフローと同じですが、アクセストークンを取得するための最終リクエストを行うときに、次のパラメーターも指定する必要がある点が異なります。

code_verifier=[Code Verifier that was transformed and sent as code_challenge previously]

クライアント資格情報とリソース所有者フロー

他にあまり使用されないフローが 2 つあります。 2つのサーバーが合意された、ユーザー中心でないデータを交換するシナリオがある場合は、ユーザーの［Allow/Deny］画面をバイパスして、クライアントを承認できます。これはクライアント資格情報フローと呼ばれ、次の URL パターンを使用します。

https://[hostname]/o/oauth2/token?grant_type=client_credentials&client_id=[client ID]&client_secret=[client secret]

ユーザーがパスワードを使用してアプリケーションを信頼する最終フローはまれですが、可能です。これはリソース所有者パスワードフローと呼ばれ、その URL パターンは次のようになります。

https://[hostname]/o/oauth2/token?grant_type=password&client_id=[client ID]&client_secret=[client secret]&username=[user@emailaddress.com]&password=

ユーザーはパスワードの入力を求められ、ログインに成功すると認証コードを受け取ります。

トークンの使用

上記のすべてのフローの結果、認可サーバー (Liferay) からクライアントアプリケーションにアクセストークンが送信されます。このトークンは、クライアントアプリケーションが保存して、将来のデータ要求とともに送信できるように、応答で送信されます。

たとえば、認証コード 946856e2b5ddf0928f6fc55f657bab73 がクライアントアプリケーションに送信されたとします。クライアントがデータを要求する場合、このコードを各リクエストヘッダーで送信する必要があります。 Curl などのコマンドライン HTTP クライアントを使用すると、次のようなリクエストを送信できます。

curl -H 'Authorization: Bearer 946856e2b5ddf0928f6fc55f657bab73' 'https://[hostname]/o/api/sample2'

ユーザーは、資格情報を共有せずに、OAuth を使用してクライアントアプリケーションに特定のサービス (スコープ) へのアクセスを許可できます。

アクセスの取り消し

アクセスが許可されると、ユーザーまたは管理者はいつでも自由にアクセスを取り消すことができます。クライアントでこの状況が発生すると、トークンは無効になり、クライアントはユーザーに再度認証を求める必要があります。これにより、ユーザーは自分のデータにアクセスできるユーザーを制御できるようになり、いつでもこの制御を行うことができます。

ユーザーは、自分のアカウントプロファイル内のデータにアクセスできるアプリケーションを完全に制御できます。

ユーザーは自分のアカウント領域で、［接続済みのアプリケーション］をクリックして、自分のアカウントへのアクセスを許可したアプリケーションのリストを表示できます。ここから、アクションメニューの［Remove Access］アイテムまたはアプリケーションの詳細画面の［Remove Access］ボタンをクリックして、アクセスを取り消すことができます。

［接続済みのアプリケーション］では、ユーザーは承認されたアプリを表示してアクセスを取り消すことができます。

管理者は、 コントロールパネル → 構成 → OAuth 2 管理にある任意のアプリの [承認] タブで承認を表示できます。アプリが信頼されている場合、または [デバイスを記憶する] ボックスがオンになっている場合は、その情報が表示されます。

アプリのすべての権限は、アプリの［権限］タブに表示されます。

リストされている承認の［Revoke］ボタンをクリックすると、そのユーザーのアカウントへのそのアプリケーションのアクセスが取り消されます。

概要

ユーザーは、資格情報を共有する必要なく、OAuth 2.0 による完全かつ安全な認証フローを取得できます。システムでアプリケーションを作成した後、安全なトークンによって特定の範囲の情報へのアクセスが可能になります。このアクセスはいつでも取り消すことができるため、OAuth 2.0 はユーザーと開発者の両方にとって必要な情報にアクセスするための便利な方法となります。

Capability: