Auth0を使用してSPAと他のバックエンドサービスのAPIリクエストを承認

Question

私たちはバックエンドサービス（C＃とPython）を呼び出すSingle Page Appを持っており、Auth0 SPAフローを使用してこれらのリクエストを認証します。

私たちのバックエンドサービスは、SPAユーザからのリクエストの処理の一部としてお互いにリクエストするだけなので、現在、SPAリクエストからのAuthorizationヘッダーを転送して、呼び出された各サービスでオペレーションを認証します。

私たちのサービス間でリクエストを行い、既存のエンドポイントを呼び出すバックエンド処理ジョブを追加したいと考えています。これらのリクエストは、転送する既存の認証ヘッダーを持たないため、独自の認証ヘッダーを構築する必要があります。 Auth0ドキュメントに基づいて

は

、hereとhereは、私はクライアントの資格付与を使用してこれらの要求を承認するべきと考えている、と私は、当社の既存のエンドポイントは、したがって、2つの異なる方法で認可要求を受け入れる必要があることを推測：SPAからまたは他のサービスから取得することができます。

SPAのJWTは1つの秘密鍵で署名され、サービスからのJWTはそれぞれの秘密鍵で署名されるという問題があります。これらの秘密鍵のいずれかを使用して構築されたJWTを受け入れるようにエンドポイントを設定する必要がありますか？

私の中核的な質問はです：この理解は正しいのですか、それとも全く別のやり方ですべきですか？

詳細：

私たちのエンドポイントを処理するために必要となる認証JWTトークンの2種類があります：私たちのSPAから

1要求、含む：

sub: SPA-USER-ID 
aud: SPA-CLIENT-ID 

は（のためHS256を使用して署名しました歴史的理由）に基づいています。含む

2サービス・ツー・サービスの要求、：

sub: SERVICE-ID@clients 
aud: API-ID 
scope: "" 

は、当社の電話サービスのクライアントシークレットを使用して（物事をシンプルに保つために今のところ）HS256を使用して署名しました。

1つのエンドポイントが両方の要求をデコードして検証する場合、最初に 'aud'値が異なるために失敗します。私は、既存のSPA呼び出しの「aud」値はエラーだと思います。要求を受け取ったAPIのIDでなければなりません。両方のリクエストの 'aud'値は同じになります。

次の違いは、それぞれ異なる秘密鍵で署名されていることです（SPAまたは呼び出し側のサービスのいずれかです）。またAuth0が推奨するようにRS256を使用して新しいサービス呼び出しを行うことを選択した場合、 ）

異なるキーでエンコードされたトークンを受け入れるようにPythonとC＃のクイックスタートを変更する明白な方法を見つけることができません。私は自分でそれをコード化することを考えています。手作業で試してみましょう。失敗したらもう片方を試してみてください。私はPythonエンドポイント認可のためにそれを行うことができると確信しています。私はPyJWTを使用したAuth0クイックスタートに基づいて作成しましたが、Auth0クイックスタートに基づいていますが、組み込みのC＃ .NET JWTの検証ミドルウェアであり、私は上記の機能を追加するためにその内部に入ることはできません。

私はこれを正しい方法でやっていれば、確かにこれは共通の要件ですか？

この質問がひどい場合、私はauthについては何も知らないし、Auth0/Oath2のドキュメントを読んで私が行っているように理解しています。

Answer 1

（第3者に、自分の質問に答える）

が正しいこのような理解です、または私はそれを完全に別の方法をやるべき？

質問で概説された全体の流れは正しいです。

サービス（またはSPA）がAuth0（または任意の発行元）から新しいアクセストークンを要求するとき、それらが提供する秘密鍵は通常、返されたトークンに署名するためにAuth0が使用するものではありません。代わりに、発行者は視聴者の秘密鍵（このアクセストークンを使用して呼び出されるAPI）を使用します。

OPがこれについて混乱させる理由は、質問に記載されているとおり、トークンを要求するときにSPA自体の「オーディエンス」値を渡します。したがって、結果として生じるトークンは、SPAの秘密を使用して署名される。これは「観客」としてAPIのIDを使用するように、固定されたら、その後、トークンはSPAのために生成し、サービス間の通話のために生成されたものは全てます：

1. 、聴衆= API-IDが含まれていますしたがって、「サブ」（ユーザID）および「スコープ」（現在は使用されていません）を除いて、すべての点で同等のペイロードが含まれます。

2. 聴衆のAPI-SECRETを使用してHS256で署名します。

したがって、エンドポイントは、2つの異なる秘密鍵を使用してエンコードされた2種類のトークンをチェックする必要はありません。それは、自身の「オーディエンス」識別子とそれ自身の秘密鍵を使用して着信要求をチェックするだけで、SPAと他のサービスからの要求を正常にデコードして検証します。