OAuth 2.0 許可種別

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

  • ​AUTHORIZATION_CODE​

  • IMPLICIT

  • ​RESOURCE_OWNER_PASSWORD_CREDENTIALS​

  • ​CLIENT_CREDENTIALS​

OAuth 2.0 セキュリティスキーマで RAML を更新する必要がある RAML ベースの API については、次の表で、RAML 許可種別と OAuth 2.0 ポリシー設定の許可種別名を対応付けています。

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

[implicit]

暗黙的

はい

[client_credentials]

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

いいえ

[password]

リソース所有者パスワードログイン情報

いいえ

[authorization_code]

認証コード

はい

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

認証コード許可種別

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

この許可種別を使用してトークンを取得するには、プロバイダへの 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

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub