JWT（Json Web Token）オーディエンス「aud」とClient_Id-違いは何ですか？
認証サーバーでOAuth 2.0 JWT access_tokenの実装に取り組んでいます。しかし、JWT audクレームとclient_id HTTPヘッダー値の違いは明確ではありません。彼らは同じですか？そうでない場合、2つの違いを説明できますか？
私の疑いは、audがリソースサーバーを参照し、client_idが認証サーバー（つまり、WebアプリまたはiOSアプリ）によって認識されるクライアントアプリケーションの1つを参照する必要があることです。
私の現在の場合、リソースサーバーはWebアプリクライアントでもあります。
結局のところ、私の疑いは正しかった。 JWTのオーディエンスaudクレームは、トークンを受け入れる必要があるリソースサーバーを参照するためのものです。
this postは単純に次のように置きます：
トークンの対象者は、トークンの対象受信者です。
オーディエンス値は文字列です。通常は、
https://contoso.comなど、アクセスされるリソースのベースアドレスです。
OAuthのclient_idは、リソースサーバーからリソースを要求するクライアントアプリケーションを指します。
クライアントアプリ（iOSアプリなど）は、認証サーバーからJWTを要求します。そうすることで、client_idとclient_secretを必要なユーザー資格情報とともに渡します。認可サーバーは、client_idおよびclient_secretを使用してクライアントを検証し、JWTを返します。
JWTには、JWTが有効なリソースサーバーを指定するaudクレームが含まれます。 audにwww.myfunwebapp.comが含まれているが、クライアントアプリがwww.supersecretwebapp.comでJWTを使用しようとすると、リソースサーバーはJWTが意図されていないことを認識するため、アクセスが拒否されます。
JWT aud（オーディエンス）クレーム
RFC 7519 によると：
「aud」（オーディエンス）クレームは、JWTが対象とする受信者を識別します。 JWTを処理することを意図した各プリンシパルは、オーディエンスクレームの値で自身を識別する必要があります。クレームを処理するプリンシパルが、このクレームが存在するときに「aud」クレームの値で自身を識別しない場合、JWTは拒否されなければなりません。一般的な場合、「aud」値は、大文字と小文字を区別する文字列の配列であり、各文字列にはStringOrURI値が含まれます。 JWTにオーディエンスが1人いる特別な場合、「aud」値は、StringOrURI値を含む単一の大文字と小文字を区別する文字列にすることができます。 視聴者の価値の解釈は、一般的にアプリケーション固有です。この主張の使用は任意です。
仕様で定義されているオーディエンス（aud）クレームは一般的であり、アプリケーション固有です。使用目的は、トークンの対象受信者を識別することです。受信者が意味することは、アプリケーション固有です。オーディエンス値は文字列のリストであるか、audクレームが1つだけの場合は単一の文字列にすることができます。トークンの作成者は、audが正しく検証されることを強制しません。責任は、トークンを使用する必要があるかどうかを受信者が判断することです。
値が何であれ、受信者がJWTを検証し、トークンがその目的に使用されることを検証したい場合、audのどの値が自身を識別するかを決定しなければならず、トークンは受信者の宣言されたIDはaudクレームに存在します。これがURLであるか、他のアプリケーション固有の文字列であるかは関係ありません。たとえば、システムがaudで文字列api3.app.comで自身を識別すると決定した場合、audクレームにオーディエンス値のリストにapi3.app.comが含まれる場合にのみJWTを受け入れる必要があります。
もちろん、受信者はaudを無視することを選択できます。そのため、受信者がトークンが具体的に作成されたという肯定的な検証を希望する場合にのみ役立ちます。
仕様に基づく私の解釈では、audクレームは、特定の目的にのみ有効な専用JWTを作成するのに役立ちます。あるシステムでは、トークンは一部の機能では有効であるが、他の機能では有効ではないことを意味する場合があります。同じキーと検証アルゴリズムを使用しながら、特定の「オーディエンス」のみに制限されたトークンを発行できます。
一般的なケースでは、JWTは信頼できるサービスによって生成され、他の信頼できるシステム（無効なトークンを使用したくないシステム）によって使用されるため、これらのシステムは使用する値を調整するだけです。
もちろん、audは完全にオプションであり、ユースケースがそれを保証しない場合は無視できます。特定の対象者によるトークンの使用を制限したくない場合、または実際にどのシステムもaudトークンを検証しない場合、それは役に立ちません。
例：アクセストークンと更新トークン
私が考えることができる1つの不自然な（まだ簡単な）例は、おそらく、個別の暗号化キーとアルゴリズムを実装せずにアクセストークンとリフレッシュトークンにJWTを使用したいが、単にアクセストークンがリフレッシュトークンとして検証されないことを確認したい、またはその逆です-その逆。
audを使用することにより、これらのトークンの作成時に、リフレッシュトークンに対してrefreshの要求を指定し、アクセストークンに対してaccessの要求を指定できます。更新トークンから新しいアクセストークンを取得する要求が行われた場合、更新トークンが真の更新トークンであることを検証する必要があります。上記のaud検証では、refresh内のaudのクレームを具体的に検索することにより、トークンが実際に有効なリフレッシュトークンであったかどうかがわかります。
OAuthクライアントIDとJWT audクレーム
OAuthクライアントIDは完全に無関係であり、JWT audクレームと直接相関していません。 OAuthの観点から見ると、トークンは不透明なオブジェクトです。
これらのトークンを受け入れるアプリケーションは、これらのトークンの意味を解析および検証する責任があります。 JWT audクレーム内でOAuthクライアントIDを指定してもあまり価値がありません。