2016-11-04 9 views
0

somedomain.comで保護するAPIがあるとします。 1ページのアプリケーションクライアントは、それを使用したいと考えて、auth.somedomain.comに認証用のエンドポイントを設定します。このアプリはcoolapps.comから提供されています。許可されたOriginをJWTトークンに入れますか?

このアプリケーション固有の認証エンドポイントで成功したログインに発行されたJWTトークンにcoolapps.comを入れますか?そのトークンは、ブラウザが誤動作していないと仮定すると、coolapp.comからロードされたばかりのスクリプトに制限され、他のドメインには制限されません。

許可されたドメインは、JWTトークンの「aud」フィールド(対象ユーザー)に入るのですか?

===

注、その目的は、クロスサイトリクエストフォージェリを阻止するだろう。 APIは、第三者サイトのアプリケーションがアクセスできるように、クロスドメイン要求を許可する必要があります。認証トークンが要求の発信元のドメインと一致することを確認するために追加のチェックが行われます。

答えて

0

はい、auth.somedomain.comが単にcoolapps.com以外のものにトークンを提供する場合、それは本当に重要になります。オーディエンスがない場合、あるドメインの管理者/アプリケーション開発者は、別のドメインに対してトークンを再生して、エンドユーザーになりすますことができます。

より細かいアプリケーション環境、つまりサブドメインの異なる管理者や同じドメインで管理されている異なるアプリケーションの場合は、audフィールドのサブドメインまたは個々のアプリケーション識別子を使用してさらに視聴者を制限することができます。

+0

「個々のアプリケーション識別子」とはどういう意味ですか? SPAで秘密にすることはできないので、クライアントの秘密を持つことはできません。だから、私は、ドメインごとにクライアントを制限することが、「aud」フィールドをうまく利用していると思うのです。 – user2800708

+0

公平なポイント、SPAユースケースでは "API識別子"となります。 OAuthでは、オーディエンスはクライアントではなく保護されたリソースです –

関連する問題