メインコンテンツへスキップ
ExampleCoでは、認可されたユーザーとアプリケーションだけがタイムシートAPIにアクセスできるように、OAuth 2.00の認可フレームワークを使用することに決めました。このフレームワークは、異なる付与タイプを使用して、タイムシートAPIと通信する必要があるさまざまな種類のアプリケーションを簡単に認可できるため、同社が求めている柔軟性を提供しています。

​
API認証と認可

APIは、アプリケーションの機能性を他のアプリケーションに公開する手段になります。アプリケーションは、APIエンドポイントにメッセージを送信することで要求を行い、応答として情報を受信することができます。 APIエンドポイントはセキュリティ保護されている場合と、そうでない場合があります。この例では、タイムシートAPI審査や財務情報などの機密情報であるため、認可されたユーザーとアプリケーションだけがAPIのエンドポイントを呼び出せるようにしなければなりません。クライアントアプリケーションがAPIの保護されたエンドポイントにアクセスしたい場合は、エンドポイントへの呼び出しに必要なアクセス許可を備えている証拠としてアクセストークンを提示する必要があります。 アクセストークンは認証サーバーでユーザーを認証することにより取得され、ユーザーはアプリケーションが自身の代理でAPIにアクセスすることを許可できます。

アクセストークンとは

アクセストークン（access_tokenとも呼ばれる）は、アプリケーションに対して発行された認可を表す、不透明な文字列です。この文字列は、認証情報の取得に使う識別子の場合もあれば、認証情報そのもの（たとえば、ユーザーのID、アクセス許可など）を検証可能な形で含んでいることもあります。アクセストークンはたいていの場合、JSON Web Tokenとして実装されます。Auth0アクセストークンの詳細については、「アクセストークン」を参照してください。
APIは、APIが公開するさまざまなエンドポイントに誰がアクセスを許可されるかについて、きめ細かい制御を行うことができます。これらのアクセス許可はスコープと呼ばれます。 ユーザーがクライアントアプリケーションを認可すると、アプリケーションは必要とされるアクセス許可も指定することができます。ユーザーはこれらのアクセス許可を確認して付与します。そして、これらのアクセス許可がscopeクレームの一部としてアクセストークンに含まれます。 その後、クライアントがAPIへの要求でアクセストークンを渡すと、APIはscopeクレームを調査し、特定のAPIエンドポイントを呼び出すために必要なアクセス許可が付与されていることを確認します。

スコープとは

それぞれのアクセストークンには、クライアントに付与されたアクセス権限のリストが含まれます。クライアントがAuth0で認証を行う際、要求するスコープ（アクセス許可）のリストを指定します。スコープが認可されると、アクセストークンに認可されたスコープのリストが含められます。たとえば、タイムシートAPIは、タイムシートの読み取り（スコープ：read:timesheets）、タイムシートの作成（スコープ：create:timesheets）、タイムシートの削除（スコープ：delete:timesheets）、タイムシートの承認（スコープ：approve:timesheets）という異なる4レベルの認可を受け入れることができます。クライアントがAPIに新しいタイムシートエントリーの作成を依頼するときは、アクセストークンにcreate:timesheetsスコープが含まれなくてはなりません。同様に、既存のタイムシートを削除するには、アクセストークンにdelete:timesheetsスコープが含まれなくてはなりません。スコープの詳細については、「スコープ」を参照してください。
Authorization Framework使用することで、独自のアプリケーションや社外の請負業者向けのサードパーティアプリケーションは、アプリケーション自体に代わってAPIに制限付きでアクセスできるようになります。Auth0を使用することで、OAuth 2.0/ Connect（OIDC）の仕様や、API認証に関する他の多くの技術的側面を心配することなく、独自のAPIで異なる認証フローを簡単にサポートすることができます。

OAuthロール

OAuth 2.0フローでは、次のロールが識別されます：
  • リソース所有者（Resource Owner） ：保護されたリソースへのアクセス権を付与できるエンティティ。通常は、エンドユーザーです。
  • リソースサーバー（Resource Server） ：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。
  • クライアント（Client） ：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。
  • 認可サーバー（Authorization Server） ：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この場合、Auth0の認証APIになります。
付与タイプ（またはフロー）は、これらの関係者がどのように作用し、ビルド中のAPIへの制限付きアクセスをアプリに付与するのかを決定します。そして、ユーザーの代わりにAPIを呼び出すためのアクセストークンをアプリが取得します。

​
Proof Key for Code Exchange（PKCE）

OAuth 2には、異なるユースケースにいくつかの付与タイプが用意されます。この特定のユースケースでは、モバイルアプリケーションからAPIにアクセスしたいとします。そのためには、Proof Key for Code Exchange（PKCE）を使った認可コードフローを使用します。 Proof Key for Code Exchange（PKCE）は、RFC 7636で定義されており、悪意ある攻撃者がAuth0から返されたauthorization_codeを横取りし、アクセストークン（および場合によってはリフレッシュトークン）と交換する、認可コード横取り攻撃を軽減するために使用される手法です。 アプリケーションはPKCEを使って、それぞれの認可要求にcode_verifierと呼ばれる暗号的にランダムなキーと、それから生成されるcode_challengeと呼ばれる値を作成します。そして、このキーはauthorization_codeを取得するためにAuth0に送られます。アプリケーションがauthorization_codeを受け取ると、コードとcode_verifierをAuth0のトークンエンドポイントに送信し、要求されたトークンと交換します。
  1. アプリはフローを開始して、ユーザーをAuth0（具体的には/authorizeエンドポイント）にリダイレクトし、code_challengeパラメーターとcode_challenge_methodパラメーターを送ります。アプリは、認証に成功した後に送信するcode_verifierも生成します。
  2. Auth0がユーザーを認証します。
  3. ユーザーが認証に成功すると、Auth0は、クエリ文字列にauthorization_codeを持つアプリにユーザーをリダイレクトします。
  4. アプリはcode_verifierをredirect_uri とclient_id と一緒にAuth0に送ります。これは、/oauth/token endpointを使って行われます。
  5. Auth0はこの情報を検証し、アクセストークン（と任意でリフレッシュトークン）を返します。
  6. アプリはアクセストークンを使って、ユーザーの代わりにAPIを呼び出します。
［Refresh Token Rotation（リフレッシュトークンのローテーション）］を有効にした場合、要求ごとに新しいリフレッシュトークンが生成され、アクセストークンと共に発行されます。リフレッシュトークンが交換されると、前のリフレッシュトークンは失効しますが、関係についての情報は認可サーバーによって維持されます。

​
認可拡張機能

Auth0認可拡張機能を使うと、ロール、グループ、権限を構成し、ユーザーに割り当てることができます。
  • 権限とは、ユーザーが行うことができるアクションです。ExampleCoの事業上のニーズに合わせ、タイムシートの読み取り、作成、削除、および承認の4つの権限が構成されます。
  • ロールとは、権限の集合です。ExampleCoのタイムシートアプリは、それぞれ異なる権限を持つ2種類のユーザー（従業員とマネージャー）によって使用されるので、従業員とマネージャーという2つのロールが構成されます。
これで事業上のニーズはカバーされるため、この場合にはグループは作成しません。 認可拡張機能は、ユーザーに割り当てられたロール、グループ、および権限を読み取り、この情報を認証フローでユーザープロファイルに追加するルールを作成します。この情報を使用して、ユーザーに発行されたアクセストークンに、認可拡張機能で定義された権限が許すスコープのみが含まれるようにします。後から、ユーザーに必要な権限がない場合はタイムシートの承認機能を無効にするなど、アプリのカスタマイズに進むことができます。