OAuth は、API エンドポイントを API クライアント間のマシン同士の通信の一部として確保する承認プロトコルです。Web クライアントの承認を重視する SAML とは異なり、OAuth が重視するのはアクションの実行者が誰かではなく、アクションの実行者が持つアクセス権の種類です。OAuth 2.0 仕様では、リソース所有者 (ユーザ)、クライアント (Address Manager API へのアクセス権を必要とするアプリケーションまたはスクリプト)、承認サーバ (OAuth2 サーバ、OpenID 接続)、リソース サーバ (Address Manager API) の 4種類のアクション実行者を指定しています。承認サーバがクライアントに対してアクセス トークン (API エンドポイントへの要求の承認に使用される) を発行し、承認許可がクライアントのアクセス トークンの取得方法を定義します。承認許可の詳細は、「https://tools.ietf.org/html/rfc6749」を参照してください。
OAuth が Address Manager で機能する仕組み
- 承認コード許可
- 暗黙的な許可
- リソース所有者パスワード資格情報許可
承認コード許可
この承認許可では、ユーザは、承認サーバによってホストされるログイン ページ (ユーザエージェント) を介して承認されます。
下の図は、承認コード許可の仕組みを示しています。
- クライアントは、ユーザエージェントを承認サーバへリダイレクトします。
- 承認サーバは、ユーザエージェントを介してユーザを承認します。
- ユーザの承認が成功し、ユーザが要求されたリソースに対するアクセスを許可する場合、承認サーバは承認コードを返し、ユーザをクライアントへリダイレクトします。
- クライアントは、承認コードを含めることで承認サーバからアクセス トークンを要求します。
- 承認サーバがクライアントを承認します。
- クライアントは、アクセス トークンを使用してリソース サーバでリソースにアクセスします。
暗黙的な許可
承認コード許可と同様に、ユーザは承認サーバによってホストされるログイン ページ (ユーザエージェント) を介して承認されますが、承認コードの代わりに、アクセス トークンがクライアントに直接返されます。
下の図は、暗黙的な許可の仕組みを示しています。
- クライアントは、ユーザエージェントを承認サーバへリダイレクトします。
- 承認サーバは、ユーザエージェントを介してユーザを承認します。
- ユーザの承認が成功し、ユーザが要求されたリソースに対するアクセスを許可する場合、承認サーバは断片化されたアクセス トークンを返し、ユーザをクライアントへリダイレクトします。
- ユーザエージェントは、フラグメント化せずに Web ホスト クライアント リソースへの要求を実行します。
- Web ホスト クライアントは、アクセス トークンを抽出可能なスクリプトをユーザエージェントに返します。
- ユーザエージェントは、スクリプトを実行してアクセス トークンを抽出します。
- ユーザエージェントは、アクセス トークンをクライアントに受け渡します。
- クライアントは、アクセス トークンを使用してリソース サーバでリソースにアクセスします。
リソース所有者パスワード資格情報許可
この承認許可では、クライアントはユーザから資格情報を要求します。つまり、この許可では、承認サーバによってホストされるログイン ページは介入しません。
下の図は、リソース所有者パスワード資格情報許可の仕組みを示しています。
- ユーザがクライアント アプリケーションにユーザ名とパスワードを入力します。
- クライアントが資格情報を承認サーバへ転送します。
- 承認サーバがアクセス トークンをクライアント アプリケーションに返します。
- クライアント アプリケーションは、アクセス トークンを使用して Address Manager を呼び出します。