ソリューションの概要（モバイルアプリ + API）

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スコープが含まれなくてはなりません。

スコープの詳細については、「スコープ」を参照してください。

OAuth 2.0 Authorization Framework使用することで、独自のアプリケーションや社外の請負業者向けのサードパーティアプリケーションは、アプリケーション自体に代わってAPIに制限付きでアクセスできるようになります。Auth0を使用することで、OAuth 2.0/OpenID 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）を使った認可コードフローを使用します。

認証コードフローには、ネイティブアプリケーションでの実装に関してセキュリティ上の問題がいくつかあります。たとえば、Auth0から返されたauthorization_codeを悪意のある攻撃者が傍受し、これをアクセストークン（場合によっては、リフレッシュトークン）と交換する可能性があります。

RFC 7636で定義されているProof Key for Code Exchange（PKCE）は、この認可コードの傍受攻撃を軽減するために用いられる手法です。

アプリケーションはPKCEを使って、それぞれの認可要求にcode_verifierと呼ばれる暗号的にランダムなキーと、それから生成されるcode_challengeと呼ばれる値を作成します。そして、このキーはauthorization_codeを取得するためにAuth0に送られます。アプリケーションがauthorization_codeを受け取ると、コードとcode_verifierをAuth0のトークンエンドポイントに送信し、要求されたトークンと交換します。

図 - マイクロサイト - PKCEを使った認証コード

  1. ネイティブアプリはフローを開始して、ユーザーをAuth0（具体的には/authorizeエンドポイント）にリダイレクトし、code_challengeパラメーターとcode_challenge_methodパラメーターを送ります。

  2. Auth0は、クエリ文字列にauthorization_codeを持つネイティブアプリにユーザーをリダイレクトします。

  3. ネイティブアプリは、authorization_codeとcode_verifierをredirect_uriとclient_idと一緒にAuth0に送ります。これは、/oauth/token endpointを使って行われます。

  4. Auth0はこの情報を検証し、アクセストークン（と任意でリフレッシュトークン）を返します。

  5. ネイティブアプリはアクセストークンを使って、ユーザーの代わりにAPIを呼び出します。

認可拡張機能

Auth0のAuthorization Extension（認可拡張機能）はユーザーにロール、グループとアクセス許可を割り当てることにより、アプリケーション内で認可に対応できるようにします。

認可拡張機能はルールを作成し、認証フローの中で、ユーザーに割り当てられたロール、グループとアクセス許可を使ってユーザープロファイルを増補します。この情報を使用して、ユーザーに発行されたアクセストークンに、認可拡張機能で定義された権限が許すスコープのみが含まれるようにします。

前のチュートリアル はじめに

次のチュートリアル 2.Auth0の構成