私は認証サーバーにOAuth 2.0 JWT access_tokenを実装する作業をしています。ただし、JWT audクレームとclient_idHTTPヘッダー値の違いは明確ではありません。彼らは同じですか？そうでない場合、2つの違いを説明できますか？

私の疑いはaud、リソースサーバーclient_idを参照する必要があり、認証サーバーによって認識されるクライアントアプリケーションの1つを参照する必要があるということです（つまり、WebアプリまたはiOSアプリ）。

現在のケースでは、リソースサーバーはWebアプリクライアントでもあります。

結局のところ、私の疑いは正しかった。audJWT のオーディエンスクレームは、トークンを受け入れる必要があるリソースサーバーを参照するためのものです。

このポストは、単にそれを置きます：

トークンの対象者は、トークンの意図された受信者です。

オーディエンスの値は文字列です。通常、などのアクセスされるリソースのベースアドレスですhttps://contoso.com。

client_idOAuthの中には、リソースサーバからリソースを要求されたクライアントアプリケーションを指します。

クライアントアプリ（iOSアプリなど）は、認証サーバーからJWTをリクエストします。そうすることで、それはそれはだ渡すclient_idと、client_secret必要な場合があります任意のユーザーの資格情報と一緒に。Authorization Serverはclient_id、client_secretおよびを使用してクライアントを検証し、JWTを返します。

audJWTには、JWTが有効なリソースサーバーを指定するクレームが含まれます。にはaudが含まれているwww.myfunwebapp.comが、クライアントアプリがでJWTを使用しようとすると、www.supersecretwebapp.comそのリソースサーバーはJWTがそのためのものではなかったことがわかるため、アクセスが拒否されます。

JWT aud（オーディエンス）クレーム

RFC 7519によると：

"aud"（audience）クレームは、JWTの対象となる受信者を識別します。JWTを処理することを目的とした各プリンシパルは、オーディエンスクレームの値で自身を識別しなければなりません。このクレームが存在するときに、クレームを処理するプリンシパルが「aud」クレームの値で自分自身を識別しない場合、JWTは拒否される必要があります。一般的な場合、「aud」値は、大文字と小文字が区別される文字列の配列であり、それぞれにStringOrURI値が含まれています。JWTが1つのオーディエンスを持つ特殊なケースでは、「aud」値は、StringOrURI値を含む単一の大文字と小文字を区別する文字列である場合があります。 オーディエンス値の解釈は、一般にアプリケーション固有です。 このクレームの使用はオプションです。

aud仕様で定義されているオーディエンス（）クレームは一般的であり、アプリケーション固有です。意図された用途は、トークンの意図された受信者を識別することです。受信者が意味することはアプリケーション固有です。オーディエンスの値は文字列のリストであるか、audクレームが1つしかない場合は単一の文字列にすることができます。トークンの作成者は、これaudが正しく検証されることを強制しません。トークンを使用する必要があるかどうかを判断するのは受信者の責任です。

値が何であれ、受信者がJWTを検証していて、トークンがその目的に使用されることを意図していたことを検証したい場合、それはaudそれ自体を識別する値を決定する必要があり、トークンは受信者の宣言されたIDがaudクレームに存在します。これがURLであるか、他のアプリケーション固有の文字列であるかは関係ありません。たとえば、私のシステムがaud文字列で自身を識別すると決定した場合：クレームにオーディエンス値のリストが含まれているapi3.app.com場合にのみ、JWTを受け入れる必要があります。audapi3.app.com

もちろん、受信者はを無視することを選択できますaud。そのため、これは、受信者がトークンが特別に作成されたという肯定的な検証が必要な場合にのみ役立ちます。

仕様に基づく私の解釈は、このaud主張は特定の目的にのみ有効な専用のJWTを作成するのに役立つというものです。1つのシステムでは、これは、トークンを一部の機能では有効にしたいが、他の機能では無効にしたい場合があることを意味します。同じキーと検証アルゴリズムを使用しながら、特定の「オーディエンス」のみに制限されたトークンを発行できます。

通常の場合、JWTは信頼できるサービスによって生成され、他の信頼できるシステム（無効なトークンを使用したくないシステム）によって使用されるため、これらのシステムは、使用する値を調整するだけで済みます。

もちろん、これaudは完全にオプションであり、ユースケースで正当化されない場合は無視できます。トークンを特定の対象者が使用するように制限したくない場合、または実際にシステムがaudトークンを検証しない場合、トークンは役に立ちません。

例：アクセストークンと更新トークン

私が考えることができる1つの工夫された（まだ単純な）例は、おそらく、個別の暗号化キーとアルゴリズムを実装する必要なく、アクセストークンと更新トークンにJWTを使用したいが、アクセストークンが更新トークンとして検証されないことを確認したい、またはその逆です-versa。

を使用audすることにより、これらのトークンを作成するときにrefresh、更新トークンとaccessアクセストークンの要求を指定できます。リフレッシュトークンから新しいアクセストークンを取得するリクエストが出された場合、リフレッシュトークンが本物のリフレッシュトークンであることを検証する必要があります。aud上記のような検証は、トークンは、実際の請求のために特別に見ることにより、トークンの有効なリフレッシュあったかどうかを教えてくれるrefreshの中でaud。

OAuthクライアントIDとJWT audクレーム

OAuthクライアントIDは完全に無関係であり、JWT audクレームと直接の相関関係はありません。OAuthの観点からは、トークンは不透明なオブジェクトです。

これらのトークンを受け入れるアプリケーションは、これらのトークンの意味を解析および検証する責任があります。JWT audクレーム内でOAuthクライアントIDを指定してもあまり価値がありません。

OpenID Connect（OIDC）を検索するためにここに来た場合：OAuth 2.0！= OIDC

これはOAuth 2.0の及びためにタグ付けされていることを認識しない両方の規格は、しかし頻繁2つの規格の間に混同があり、OIDC でき JWTs及び使用audクレーム。そして、1つ（OIDC）は基本的にもう1つ（OAUTH 2.0）の拡張です。（私は自分自身でOIDCを探してこの質問を見つけました。）

OAuth 2.0アクセストークン##

OAuth 2.0 アクセストークンの場合、既存の回答で十分カバーできます。さらに、OAuth 2.0フレームワーク（RFC 6749）の 1つの関連セクションがあります。

暗黙的なフローを使用するパブリッククライアントの場合、この仕様では、クライアントがアクセストークンの発行先のクライアントを決定する方法は提供されていません。
...
リソース所有者をクライアントに認証することは、この仕様の範囲外です。承認プロセスをクライアントへの委任されたエンドユーザー認証の形式として使用するすべての仕様（たとえば、サードパーティのサインインサービス）は、クライアントがアクセスかどうかを判断できるようにする追加のセキュリティメカニズムなしに暗黙のフローを使用してはなりません（MUST NOT）。トークンはその使用のために発行されました（例：視聴者を制限するアクセストークン）。

OIDC IDトークン##

OIDCには、アクセストークンに加えてIDトークンがあります。OIDC仕様はaud、IDトークンでのクレームの使用に関して明示的です。（openid-connect-core-1.0）

aud
が必要です。このIDトークンの対象となるオーディエンス。オーディエンスの値として、依拠当事者のOAuth 2.0 client_idを含める必要があります。他のオーディエンスの識別子も含まれる場合があります。一般的なケースでは、aud値は大文字と小文字を区別する文字列の配列です。オーディエンスが1人の場合の一般的な特殊なケースでは、aud値は大文字と小文字を区別する単一の文字列である場合があります。

更にOIDCは指定azpと組み合わせて使用される、請求項aud場合にaud複数の値を有しています。

azp
オプション。許可されたパーティー-IDトークンが発行されたパーティー。存在する場合は、このパーティのOAuth 2.0クライアントIDを含める必要があります。このクレームは、IDトークンに単一のオーディエンス値があり、そのオーディエンスが許可されたパーティーとは異なる場合にのみ必要です。許可された当事者が単一の聴衆と同じ場合でも含まれる場合があります。azp値は、StringOrURI値を含む大文字と小文字を区別する文字列です。

これは古いですが、今日でも質問は妥当だと思います

私の疑いは、audはリソースサーバーを参照する必要があり、client_idは認証サーバーによって認識されるクライアントアプリケーションの1つを参照する必要があるということです

はい、audはトークンを消費するパーティーを参照する必要があります。そしてclient_idはトークン取得パーティを指します。

現在のケースでは、リソースサーバーはWebアプリクライアントでもあります。

OPのシナリオでは、Webアプリとリソースサーバーの両方が同じパーティに属しています。つまり、これはクライアントとオーディエンスが同じであることを意味します。ただし、これが当てはまらない場合もあります。

OAuthで保護されたリソースを消費するSPAについて考えます。このシナリオでは、SPAがクライアントです。保護されたリソースは、アクセストークンの対象です。

この2番目のシナリオは興味深いものです。承認リクエストで対象ユーザーをどこに定義できるかを説明した「OAuth 2.0のリソースインジケーター」という名前の作業ドラフトが用意されています。したがって、結果のトークンは指定されたオーディエンスに制限されます。また、Azure OIDCは同様のアプローチを使用して、リソースの登録を許可し、認証リクエストにリソースパラメーターを含めて、アクセストークンの対象となる対象者を定義できるようにします。このようなメカニズムにより、OAuthアドポテーションは、クライアントとトークンを消費する（オーディエンス）パーティを分離できます。