52.6 認可および認証エンドポイントの理解

OAuthサービスには、HTTPSリクエストを受け取ってそれに応答する4つの認証エンドポイント(認可エンドポイント、トークン・エンドポイント、プッシュ・エンドポイントおよびユーザー承認失効エンドポイント)があります。各エンドポイントは、クライアントがリクエストの作成に使用するURLです。

認証エンドポイントは次のとおりです。

• 認可エンドポイント: クライアントはリソース所有者から認可を取得して、リクエストされたリソースにアクセスするために認可エンドポイントを使用します。クライアント・アプリケーションは、認可エンドポイント・リクエストの識別子、アクセス対象のリソースを定義するリクエスト済スコープ、およびアクセスが付与または拒否されたときに、OAuthサービスがWebブラウザをダイレクトするリダイレクションURIを送信することで、認可エンドポイント・リクエストを開始します。エンドポイントは、HTTPSリクエストを受け入れます。このエンドポイントのURIの最後は常にauthorizeです。次に例を示します。

  http(s)://<host>:<port>/ms_oauth/oauth2/endpoints/<yourOauthServiceName>/authorize

• トークン・エンドポイント: クライアント・アプリケーションは、アクセス・トークンの認可コード権限を交換するために、トークン・エンドポイントと相互作用します。これは、アクセス・トークンを取得するために、「クライアント資格証明」権限タイプおよびリソース所有者資格証明の権限タイプにも使用されます。クライアントはリフレッシュ・トークンを使用して、新しいアクセス・トークンを取得します。このエンドポイントのURIの最後は常にtokenです。次に例を示します。

  http(s)://<host>:<port>/ms_oauth/oauth2/endpoints/<yourOauthServiceName>/token

• プッシュ・エンドポイント: モバイルOAuthサービス・クライアント・アプリケーションは、認可コードの一部や、Apple Push Notification Service (APNS)またはGoogle Cloud Messaging (GCM)サービスのいずれかを使用して送信されるクライアント・トークン、アクセス・トークンおよびリフレッシュ・トークンの一部(構成によって異なる)を取得するために、プッシュ・エンドポイントとやり取りします。これは、モバイル・クライアント検証コード、認可コードおよびクライアント・トークンに使用することもできます。たとえば、APNSにデータをリクエストするエンドポイントは次のとおりです。

  http(s)://<host>:<port>/ms_oauth/oauth2/endpoints/oauthservice/push
  

• ユーザー認証失効エンドポイント: リソースの所有者(エンド・ユーザー),は、ブラウザベースの認可エンドポイント・フローを使用してクライアント・アプリケーションを認証および認可し、このエンドポイントを使用してクライアント・アプリケーションに対する認証を失効させます。次に例を示します。

  http(s)://<host>:<port>/ms_oauth/oauth2/ui/<yourOauthServiceName>/showrevokeconsent

認可コード権限を持つクライアントをOAuthサーバーに構成する際には、サーバーがクライアントに認可資格証明を返すことが可能なクライアント・リダイレクトURIを少なくとも1つ提供することも必要です。

• クライアント・リダイレクトURI: OAuthサービス・サーバーは、クライアント・プロファイルで構成されたURIと正確に一致する場合に、リクエストで指定されたURIを使用して、クライアントに認可資格証明を返します。