API認証と認可
APIは、アプリケーションの機能性を他のアプリケーションに公開する手段になります。アプリケーションは、APIエンドポイントにメッセージを送信することで要求を行い、応答として情報を受信することができます。 APIエンドポイントはセキュリティ保護されている場合と、そうでない場合があります。この例では、タイムシートAPI審査や財務情報などの機密情報であるため、認可されたユーザーとアプリケーションだけがAPIのエンドポイントを呼び出せるようにしなければなりません。クライアントアプリケーションがAPIの保護されたエンドポイントにアクセスしたい場合は、エンドポイントへの呼び出しに必要なアクセス許可を備えている証拠としてアクセストークンを提示する必要があります。 アクセストークンは認証サーバーでユーザーを認証することにより取得され、ユーザーはアプリケーションが自身の代理でAPIにアクセスすることを許可できます。アクセストークンとは
アクセストークン（
access_tokenとも呼ばれる）は、アプリケーションに対して発行された認可を表す、不透明な文字列です。この文字列は、認証情報の取得に使う識別子の場合もあれば、認証情報そのもの（たとえば、ユーザーのID、アクセス許可など）を検証可能な形で含んでいることもあります。アクセストークンはたいていの場合、JSON Web Tokenとして実装されます。Auth0アクセストークンの詳細については、「アクセストークン」を参照してください。scopeクレームの一部としてアクセストークンに含まれます。
その後、クライアントがAPIへの要求でアクセストークンを渡すと、APIはscopeクレームを調査し、特定のAPIエンドポイントを呼び出すために必要なアクセス許可が付与されていることを確認します。
スコープとは
それぞれのアクセストークンには、クライアントに付与されたアクセス権限のリストが含まれます。クライアントがAuth0で認証を行う際、要求するスコープ（アクセス許可）のリストを指定します。スコープが認可されると、アクセストークンに認可されたスコープのリストが含められます。たとえば、タイムシートAPIは、タイムシートの読み取り（スコープ：
read:timesheets）、タイムシートの作成（スコープ：create:timesheets）、タイムシートの削除（スコープ：delete:timesheets）、タイムシートの承認（スコープ：approve:timesheets）という異なる4レベルの認可を受け入れることができます。クライアントがAPIに新しいタイムシートエントリーの作成を依頼するときは、アクセストークンにcreate:timesheetsスコープが含まれなくてはなりません。同様に、既存のタイムシートを削除するには、アクセストークンにdelete:timesheetsスコープが含まれなくてはなりません。スコープの詳細については、「スコープ」を参照してください。OAuthロール
OAuth 2.0フローでは、次のロールが識別されます：
- リソース所有者（Resource Owner） ：保護されたリソースへのアクセス権を付与できるエンティティ。通常は、エンドユーザーです。
- リソースサーバー（Resource Server） ：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。
- クライアント（Client） ：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。
- 認可サーバー（Authorization Server） ：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この場合、Auth0の認証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のトークンエンドポイントに送信し、要求されたトークンと交換します。
- アプリはフローを開始して、ユーザーをAuth0（具体的には/authorizeエンドポイント）にリダイレクトし、
code_challengeパラメーターとcode_challenge_methodパラメーターを送ります。アプリは、認証に成功した後に送信するcode_verifierも生成します。 - Auth0がユーザーを認証します。
- ユーザーが認証に成功すると、Auth0は、クエリ文字列に
authorization_codeを持つアプリにユーザーをリダイレクトします。 - アプリは
code_verifierをredirect_uriとclient_idと一緒にAuth0に送ります。これは、/oauth/token endpointを使って行われます。 - Auth0はこの情報を検証し、アクセストークン（と任意でリフレッシュトークン）を返します。
- アプリはアクセストークンを使って、ユーザーの代わりにAPIを呼び出します。
［Refresh Token Rotation（リフレッシュトークンのローテーション）］を有効にした場合、要求ごとに新しいリフレッシュトークンが生成され、アクセストークンと共に発行されます。リフレッシュトークンが交換されると、前のリフレッシュトークンは失効しますが、関係についての情報は認可サーバーによって維持されます。
認可拡張機能
Auth0認可拡張機能を使うと、ロール、グループ、権限を構成し、ユーザーに割り当てることができます。- 権限とは、ユーザーが行うことができるアクションです。ExampleCoの事業上のニーズに合わせ、タイムシートの読み取り、作成、削除、および承認の4つの権限が構成されます。
- ロールとは、権限の集合です。ExampleCoのタイムシートアプリは、それぞれ異なる権限を持つ2種類のユーザー（従業員とマネージャー）によって使用されるので、従業員とマネージャーという2つのロールが構成されます。