1. Homepage
  2. API Manager (2.x)
  3. Mule OAuth 2.0 プロバイダー

  4. OAuth 2.0 許可種別

OAuth 2.0 許可種別

OAuth 2.0 では、トークンの要求に次の許可種別を指定します。

  • AUTHORIZATION_CODE​

  • IMPLICIT

  • RESOURCE_OWNER_PASSWORD_CREDENTIALS​

  • CLIENT_CREDENTIALS

RAML ベースの API の場合、OAuth 2.0 セキュリティスキーマに合わせて RAML を更新する必要があります。次の表では、RAML 許可種別と OAuth 2.0 ポリシー設定の許可種別名をマップしています。

RAML 定義で定義される認証許可種別 OAuth プロバイダーポリシーで有効化する同等の認証許可種別 埋め込み APIkit コンソールのサポート対象

[implicit]

暗黙的

はい

[client_credentials]

クライアントログイン情報

いいえ

[password]

リソースオーナーのパスワードログイン情報

いいえ

[authorization_code]

認証コード

はい

詳細は、​「OAuth 2.0 ポリシーの前提条件の確認」​ドキュメントを参照してください。

Authorization Code Grant Type (認証コード許可種別)

認証コード許可種別は、最もよく使用される最も安全な許可種別です。

この許可種別を使用してトークンを取得するには、プロバイダーへの HTTP 要求に次の情報を指定する必要があります。

  • クライアントアプリケーションのクライアント ID

  • クライアントアプリケーションのクライアントシークレット

  • クライアントアプリケーション定義に指定されているリダイレクト URL

トークンを取得するためのプロバイダーへの HTTP 要求の例

プロバイダーは http://localhost:8081 でアクセスでき、クライアントアプリケーションのリダイレクト URL は「http://localhost:1234」であるとします。

認証要求:

curl “http://localhost:8081/authorize” \
-d “response_type=code&client_id=<application Client ID> \
&scope=&redirect_uri=http://localhost:1234” \
-X POST

ブラウザーにログインページが表示されます。ユーザーがログインした後、プロバイダーはリダイレクトを ​redirect_uri​ に送信します。このリダイレクトには、アクセスコードなど、追加のプロパティが含まれます。

応答:

http://localhost:1234/?code=<authorization code>#/login

要求でアクセスコードをトークンエンドポイントに送信します。他にも、クライアント ID、クライアントシークレット、前のコールの情報の一部が含まれます。

トークン要求:

curl “http://localhost:8081/access-token” \
-d “grant_type=authorization_code&client_id=<application Client ID>&client_secret=<application Client Secret> \
&code=<authorization code>&redirect_uri=<http://localhost:1234 as in the previous request>” \
-X POST

JSON 応答:

{
    "expires_in":86400,
    "token_type":"bearer",
    "refresh_token":"<oauth refresh token>",
    "access_token":"<oauth token>"
}

暗黙的

暗黙的許可種別は、認証コード許可種別ほど安全ではありませんが、より簡単に使用できます。JavaScript クライアントやモバイルアプリケーションではこの許可種別がよく使用されます。認証サーバーがアクセストークンを直接発行し、中間アクセスコードを発行するステップが省略されます。

トークンを取得するためのプロバイダーへの HTTP 要求の例

プロバイダーは http://localhost:8081 でアクセスでき、クライアントアプリケーションのリダイレクト URL は「http://localhost:1234」であるとします。

クライアント ID、実行する認証の種別、リダイレクト URL、認証するスコープを含む要求で認証エンドポイントを呼び出します。要求の構造は次の URI のようになります。

トークン要求:

curl “http://localhost:8081/authorize” \
-d “grant_type=implicit&client_id=<application Client ID> \
&redirect_uri=http://localhost:1234&response_type=token” \
-X POST

これによりブラウザーにログインページが表示されます。ユーザーがログインした後、プロバイダーはリダイレクトを ​redirect_uri​ に送信します。このリダイレクトにはすでに、アクセスコードだけでなくトークンが含まれています。

応答:

http://localhost:1234/#access_token=<oauth token>&token_type=bearer&expires_in=86400

リソースオーナーのパスワードログイン情報

リソースオーナーのパスワードログイン情報許可種別は、暗黙的および認証コード許可種別よりも安全性が低くなります。クライアントはユーザーのログイン情報を処理する必要があります。クライアントではユーザーに高いレベルの信頼が要求されます。この許可種別は多くの場合、保護されたリソースのコンシューマーが同じサービスのウィジェットである場合に使用されます。

トークンを取得するためのプロバイダーへの HTTP 要求の例

プロバイダーは http://localhost:8081 でアクセスできるとします。

ユーザー名とパスワードが含まれる POST 要求をトークンエンドポイントに送信します。

トークン要求:

curl "http://localhost:8081/access-token” \
-d “grant_type=password&response_type=token&username=<username> \
&password=<password>&client_id=<application client ID> \
&client_secret=<application client secret>" \
-X POST

JSON 応答の例:

{
    "expires_in":86400,
    "token_type":"bearer",
    "refresh_token":"<refresh oauth token>",
    "access_token":"<oauth token>"
}

クライアントログイン情報

クライアントログイン情報許可種別は、最も安全性の低い許可種別です。この許可種別は、クライアントがリソースオーナーであるか、認証が認証サーバーによってすでに処理されている場合に使用します。この許可種別では、アクセストークンは、クライアント ID とクライアントシークレットが有効な場合に取得されます。

トークンを取得するためのプロバイダーへの HTTP 要求の例

プロバイダーは http://localhost:8081 でアクセスでき、クライアントアプリケーションのリダイレクト URL は「http://localhost:1234」であるとします。

ユーザー名とパスワードが含まれる POST 要求をトークンエンドポイントに送信します。

トークン要求:

curl “http://localhost:8081/access-token” \
-d “grant_type=client_credentials&client_id=<application client ID> \
&client_secret=<application Client Secret>&response_type=token” \
-X POST

JSON 応答:

http://localhost:1234/#access_token=<oauth token>&token_type=bearer&expires_in=86400

関連情報