アプリケーションを登録したら、ユーザーの認可を開始できます。そのためには、認可サーバー（Liferay DXP）へのURLを作成する必要があります。認可サーバーは、前のチュートリアルでスコープとして定義したように、要求された権限を自分のリソースに許可するようにユーザーに要求します。
認可コードフロー
最も一般的なOAuthフローはWebアプリケーションに使用される認可コードフローです。このためのURLには、以下のリクエストパラメータが必要です。
response_typeclient_id
したがって、認可用のURLを作成するには、次のパターンに従います。
https://[hostname]/o/oauth2/authorize?response_type=code&client_id=[client ID]
クライアントIDはアプリケーションの登録に取得されます。これは、自動的に生成されます（ただし、アプリケーションを編集すれば変更できます）。
重要： 「Webアプリケーション」というフレーズが曖昧に使用されている場合があり、アプリケーションは上記のURLがWebブラウザから直接要求されていることを意味することがあります。このような場合、クライアントの秘密を漏らすことになり、認可フローとアプリケーションのセキュリティが低下します。そのような場合は、アプリケーションを登録するときに、代わりに 「ユーザーエージェントアプリケーション」のクライアントプロファイルを選択してください。これにより、アプリケーションにPKCE拡張認可コードフローという安全な代替手段が提供されます（下記参照）。
ユーザーが要求されたアクセス権限を自分のリソースに許可すると、認可サーバーは登録済みのコールバックURI（別名：リダイレクトURI）で、認可コードをクエリ文字列パラメーターとしてアプリケーションに返します。
[your callback URI]?code=[authorization server generated code]
アプリケーションは以下のパターンに従ってPOSTリクエストを送信して、その認可コードをアクセストークンと交換する必要があります。
http://localhost:8080/o/oauth2/token
以下のパラメータを本文に含めまる。（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秒を超えて）使用する予定の場合は、更新トークンも必要です。新しいアクセストークンを取得するにあたって、同じユーザー権限を使用してユーザー認可を受けずに、これを更新トークンフローと組み合わせて使用することができますアプリケーション登録がこのフローに登録されている場合にのみ、認可サーバーは更新トークンを発行します。
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つのサーバーが交換することに同意した、ユーザー中心以外のデータを交換するシナリオがある場合は、ユーザーの許可/拒否画面を省略してクライアントを認可できます。これはクライアント資格情報フローと呼ばれ、以下のURLパターンを使用します。
https://[hostname]/o/oauth2/authorize?response_type=code&grant_type=client_credentials&client_id=[client ID]&client_secret=[client secret]
最後に、ユーザーが自分のパスワードでアプリケーションを信頼するというフローは稀ですが可能です。これはリソース所有者パスワードフローと呼ばれ、そのURLパターンは次のようになります。
https://[hostname]/o/oauth2/authorize?response_type=code&grant_type=password&client_id=[client ID]&client_secret=[client secret]&username=[user@emailaddress.com]&password=
ユーザーはパスワードの入力を求められ、ログインに成功すると認可コードを受け取ります。
トークンの使用
上記のすべてのフローにより、認可サーバー（Liferay DXP）からクライアントアプリケーションに送信されるアクセストークンが生成されます。このトークンは、クライアントアプリケーションが今後のデータ要求を保存して、一緒に送信するための応答として送信されます。
たとえば、認可コードの946856e2b5ddf0928f6fc55f657bab73がクライアントアプリケーションに送信されたとします。クライアントがデータを要求すると、このコードは各要求ヘッダーで送信されなければなりません。CurlなどのコマンドラインHTTPクライアントを使用して、次のような要求を送信できます。
curl -H 'Authorization: Bearer 946856e2b5ddf0928f6fc55f657bab73' 'https://[hostname]/o/api/sample2'
OAuth 2.0は、資格情報を共有することなく、クライアントアプリケーションがユーザーによって特定のサービス（スコープ）へのアクセスへの許可を得るための便利な方法を提供します。
アクセスの取り消し
アクセスが許可されると、ユーザーまたは管理者はいつでも自由にアクセスを取り消すことができます。これがクライアントに発生した場合、トークンは無効になり、クライアントは再度認証をユーザーに要求する必要があります。これにより、ユーザーは自分のデータに何がアクセスできるかを管理でき、いつでもこの管理を実行できます。
自分のアカウント領域で、ユーザーは*[OAuth2に接続中のアプリケーション]をクリックして、自分のアカウントへのアクセスを許可されているアプリケーションのリストを見ることができます。ここから、操作メニューの[アクセス権の削除]という項目またはアプリケーションの詳細画面の[アクセス権の削除]*ボタンをクリックして、アクセス権を取り消すことができます。
管理者は、[コントロールパネル] → [設定] → *[OAuth2管理]*にある、任意のアプリの権限タブで権限を確認できます。
リストされている権限の*[取り消し]*ボタンをクリックすると、そのアプリケーションのユーザーアカウントへのアクセスが取り消されます。
まとめ
OAuth 2.0は、ユーザーが資格情報を共有しなくても、完全かつ安全な認可フローをユーザーに提供します。システム内にアプリケーションが作成されると、安全なトークンによって特定のスコープの情報にアクセスできるようになり、このアクセスはいつでも取り消すことができるため、OAuth 2.0はユーザーと開発者が必要な情報にアクセスするための便利な方法だといえます。