id_tokenとaccess_tokenの明確化
OIDCとOAuth 2.0（Auth0を使用））でシステムを構築していますが、id_tokenとaccess_tokenを適切に使用する方法がわかりません。セットアップでさまざまなサービスに割り当てる役割について混乱しています。
完全に静的なフロントエンドアプリケーション（単一ページアプリ、HTML + JS、バックエンドなし）を使用して、Auth0に対する暗黙のフローを使用してユーザーを認証します。次に、フロントエンドアプリケーションは、私も作成しているAPIからデータを取得します。
さて、どちらが正しいですか？
- フロントエンドSPAはOAuthクライアントアプリケーション
- 私のAPIサービスはOAuthresource server
...または：
- フロントエンドとAPIサービスは両方ともクライアントアプリケーションです
フロントエンドAPIとバックエンドAPIの両方をクライアントと見なすことができる場合、フロントエンドからバックエンドへのリクエストでベアラトークンとしてid_tokenを使用しても実質的な害はありません。バックエンドの署名済みトークン。必要なユーザーに関するすべての情報があります。ただし、私のAPIがリソースサーバーと見なされる場合は、おそらくaccess_tokenを使用する必要がありますが、Auth0のサーバーに接続する必要がありますトークンを検証し、基本的なユーザー情報を取得するためのすべてのAPIリクエストはありませんか？
私は this を読みました。これは、access_tokenがAPIで使用するための唯一の有効なトークンであることを示唆しているようです。しかし、私が言ったように、個々のサービスの役割についてはわかりません。また、id_tokenを使用すると魅力的です。バックエンドでネットワーク接続を必要とせず、適切なデータを抽出するために必要な情報が含まれているためです。
これについて正しい方法は何ですか？
あなたの最前線はOAuthクライアントアプリケーションです。トークンを保存して、OAuthフローでアクションを実行できます。APIサービスはリソースサービスです。 IDサーバーによって発行されたaccess_tokenを受け入れます。
また、id_tokenはログに記録されたユーザーのIDを表し、アプリの機密データが含まれている場合があります。 access_tokenは、リソースにアクセスするための資格情報として立っています。
最後にaccess_tokenを使用してリソースを要求します。ログインしているユーザー（リソース所有者）から特定のデータが必要な場合は、トークンエンドポイントからIDトークンを要求できます。
私の意見では、最初のアプローチは正しいです。 SPAはクライアントアプリケーションであり、APIはリソースサーバーです。
SPAのみにid_tokenの使用を制限することをお勧めします。 idトークンに含まれる基本情報（ユーザー名やメールなど）を使用して、UI内にユーザー情報を表示できます。アクセストークンもJWTとして生成できる場合、APIはIDプロバイダーにアクセスせずにアクセストークンを検証できます。アクセストークンにロール（または同様の）を含めて、アクセストークンの承認情報を取得できます。