OAuth 認証許可種別
OAuth コンシューマー (クライアントアプリケーション) が OAuth サービスプロバイダーから保護されたリソースへのアクセス権を取得するために使用できる 4 つの認証許可種別があります。
OAuth 認証フレームワークについては、RFC 6749 の「OAuth 2.0 認証フレームワーク」を参照してください。
認証コード
認証コード許可種別では、認証サーバー (保護されたリソースにアクセスするための権限を確認して付与する) とリソースサーバー (保護されたリソースへのアクセスを提供する) を使用します。独立したサーバーとして記述されていますが、認証サーバーとリソースサーバーは同じ Mule サーバーに存在します。認証コード許可種別を使用する場合、クライアントアプリケーションは、保護されたリソースへのアクセス権を付与するトークンを要求する前に、サービスプロバイダーに認証コードを要求する必要があります。
認証コード許可種別は、認証されていないパーティ (リソースオーナーを含む) に公開することなくクライアントを認証してアクセストークンを転送するため、特に安全です。
認証コード許可種別を使用する OAuth ダンスは次のように機能します。
-
クライアントアプリケーションはサービスプロバイダーによって制御されている、保護されたリソースを使用するために、リソースへのアクセス要求を開始します。
-
クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。
-
クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、サービスプロバイダーの認証を受けます。
-
クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーは認証コードを返します。
-
クライアントアプリケーションは、認証サーバーをもう一度コールし、認証コード、クライアント ID (再度)、クライアントシークレットを提供します。
-
サービスプロバイダーは、アクセストークンを返します。
-
クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。
-
サービスプロバイダーは、保護されたリソースを提供します。
暗黙的
認証コード許可種別と同様に、暗黙的許可種別には認証サーバーとリソースサーバーが関与します。ただし、認証コードとクライアントシークレットを使用してクライアントアプリケーションを認証するための追加手順を実行する代わりに、サービスプロバイダーは次の作業を行います。
-
クライアント ID に基づいてクライアントを認証する。
-
保護されたリソースにアクセスするためのアクセストークンを提供する。
暗黙的許可種別は、Javascript などのスクリプト言語を使用するブラウザークライアントのパフォーマンスを最適化します。ただし、この許可種別では、アクセストークンをリソースオーナーまたはリソースオーナーのユーザーエージェントに公開できます。
暗黙的許可種別を使用する OAuth ダンスは次のように機能します。
-
クライアントアプリケーションは、サービスプロバイダーの認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。
-
クライアントアプリケーションは、サービスプロバイダーによって提供されるログインページを使用して、リソースオーナーがサービスプロバイダーに対してクライアントアプリケーションを認証するように要求します。
-
クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認し、リソースオーナーのログイン情報を認証したら、サービスプロバイダーはアクセストークンを返します。
-
クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。
-
サービスプロバイダーは、保護されたリソースを提供します。
リソースオーナーパスワードログイン情報
リソースオーナーパスワードログイン情報許可種別を使用する場合、クライアントアプリケーションは、リソースオーナーがサービスプロバイダーのログイン情報を共有するように要求します。次に、クライアントアプリケーションは、それらのログイン情報を使用して、サービスプロバイダーにアクセスし、リソースオーナーのアカウントにアクセスします。サービスプロバイダーは、有効なログイン情報を受け入れて、リソースオーナーのアカウントへのフルアクセス権をクライアントアプリケーションに付与します。
この認証種別は、安全なアクセスログイン情報の共有を犠牲にしてパフォーマンスを最適化します。リソースオーナーは、クライアントアプリケーションが非公開データへのアクセス権を共有しないことを信頼する必要があります。
リソースオーナーパスワードログイン情報許可種別を使用する OAuth ダンスは次のように機能します。
-
リソースオーナーは、アクセスログイン情報をクライアントアプリケーションに提供します。
-
クライアントアプリケーションは、サービスプロバイダーをコールしてアクセストークンを要求します。クライアントは、コール時にサービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。保護されたリソースのアクセスログイン情報も提供します。
-
サービスプロバイダーは、クライアントアプリケーションを認証し、アクセスログイン情報を検証します。次に、アクセストークンを発行します。
-
クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースへのアクセスを要求するためのアクセストークンを提供します。
-
サービスプロバイダーは、保護されたリソースを提供します。
クライアントログイン情報
クライアントログイン情報許可種別を使用する場合、クライアントアプリケーションは、特定のリソースオーナーに関連付けられていないデータへのアクセスを要求します。この許可種別では、サービスプロバイダーはクライアントが有効であるかどうかのみを検証する必要があります。この種別の OAuth インタラクションは、2 つの役割 (サービスプロバイダーとクライアントアプリケーション) のみが関与するため「2 本足の OAuth」と呼ばれることがあります。 他の 3 つの認証種別は、3 番目の役割 (リソースオーナー) が関与します。そのため、「3 本足の OAuth」と呼ばれることがあります。
通常、クライアントログイン情報許可種別は、クライアントがリソースオーナーでもある場合に適用されます。
クライアントログイン情報許可種別を使用する OAuth ダンスは次のように機能します。
-
クライアントアプリケーションは、認証サーバーをコールし、サービスプロバイダーの登録済みクライアントであることを確認するためのクライアント ID を提供します。
-
クライアント ID が有効である (クライアントアプリケーションが以前にサービスプロバイダーに登録されている) ことを確認しら、サービスプロバイダーはアクセストークンを返します。
-
クライアントアプリケーションは、リソースサーバーをコールし、保護されたリソースを要求するためのアクセストークンを提供します。
-
クライアントアプリケーションは、保護されたリソースを取得します。