Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerOAuth 2.0 では、トークンの要求に次の許可種別を指定します。
AUTHORIZATION_CODE
IMPLICIT
RESOURCE_OWNER_PASSWORD_CREDENTIALS
CLIENT_CREDENTIALS
RAML ベースの API の場合、OAuth 2.0 セキュリティスキーマに合わせて RAML を更新する必要があります。次の表では、RAML 許可種別と OAuth 2.0 ポリシー設定の許可種別名をマップしています。
RAML 定義で定義される認証許可種別 | OAuth プロバイダーポリシーで有効化する同等の認証許可種別 | 埋め込み APIkit コンソールのサポート対象 |
---|---|---|
|
暗黙的 |
はい |
|
クライアントログイン情報 |
いいえ |
|
リソースオーナーのパスワードログイン情報 |
いいえ |
|
認証コード |
はい |
詳細は、「OAuth 2.0 ポリシーの前提条件の確認」ドキュメントを参照してください。
認証コード許可種別は、最もよく使用される最も安全な許可種別です。
この許可種別を使用してトークンを取得するには、プロバイダーへの HTTP 要求に次の情報を指定する必要があります。
クライアントアプリケーションのクライアント ID
クライアントアプリケーションのクライアントシークレット
クライアントアプリケーション定義に指定されているリダイレクト URL
プロバイダーは 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://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://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://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