タグ付けされた質問 「jwt」


1
マイクロサービスはユーザーである必要がありますか?
マイクロサービスのアクセス権を制限しながら、マイクロサービスアーキテクチャでユーザーを承認する最適な方法を決定しようとしています。このアーキテクチャでは、中央認証サービスを使用して、JWTトークンの発行を処理します。 次の要件があります。 ユーザーは特定の役割を実行するように制限する必要があります。たとえば、ユーザーは自分が所有するコンテンツのみを作成、変更、または読み取りできる必要があります。 マイクロサービスは、必要な権限のみに制限する必要があります。たとえば、別のサービスからデータを読み取るだけでよいマイクロサービスは、そのサービスへのデータの書き込みを明示的に禁止する必要があります。 例として、ユーザーが画像ストアサービスに写真をアップロードできるシステムがあるとします。写真に位置を自動的にタグ付けするタグ付けサービスがあります。ユーザーは自分の写真のみをCRUDできます。タグ付けサービスは、イメージストアサービスから任意のイメージを読み取ることができますが、変更/削除はできません。 JWTトークンを使用して上記を達成する良い方法は何ですか?私たちが議論したいくつかのソリューションは次のとおりです。 画像ストアサービスは2つのAPIを公開します。1つは外部で利用可能(ユーザーCRUDアクセスを提供)、もう1つは内部で利用可能(内部読み取り専用アクセスを提供)です。柔軟性がないようです-別の内部サービスがすべての画像(たとえば、明示的な画像を自動的に削除するもの)への読み取り/書き込みアクセスを必要とする場合はどうなりますか? ユーザーのJWTに2つの許可を設定します。1つはCRUD_OwnImagesで、もう1つはREAD_ForAnalysisです。タグ付けサービスは、ユーザーがREAD_ForAnalysis権限を持っているかどうかを確認し、もしそうであれば、適切な要求を行います。ユーザー自身の画像でのCRUD操作のためにユーザーがCRUD_OwnImagesを持っているかどうかを確認する別のマイクロサービスがあります。これにより、各マイクロサービスに責任が課され、ユーザーは必要なアクションに制限されます。画像ストアには、このアプローチで各マイクロサービスを制限する方法がないため、潜在的に不安定でエラーが発生しやすくなります。 READ_ForAnalysisを許可として、タグ付けマイクロサービスに独自のユーザーを与えます。次に、タグ付けサービスが画像ストアから画像を要求すると、それらへのアクセスが許可されますが、それらの変更は禁止されます。ユーザーのユーザーはCRUD_OwnImages権限のみを持っているため、フロントエンドから自分の画像のみを取得してアクセスすることができます。別のサービスがすべてのデータに対してCRUDを必要とする場合、CRUD_AllDataまたは同様のサービスを提供できます。各サービスが独自のデータを担当するようになったため(このロジックは複数のサービスに複製されるのではなく)このアプローチが好きですが、サービスにユーザー権限とマイクロサービス権限の両方が必要な場合はどうでしょうか?2つのJWTトークン(ユーザーとマイクロサービスの両方)を安全に送信できますか?許可を安全に組み合わせて送信する方法はありますか?例えば ユーザー情報がさらに下流に必要な場合(2または3マイクロサービス離れている)、問題は悪化します。私たちは、必要なアクションに自分自身を制限するのは個々のマイクロサービス次第であり、それを明確にしないと仮定するだけですか?

1
jwtの「aud」と「iss」の違い
より堅牢な認証サービスを実装したいのですが、やりたいことのjwt大部分を占めています。コードの記述方法は理解していますが、予約済みissとaudクレームの違いを理解するのに少し問題があります。1つはトークンを発行しているサーバーを定義し、1つは使用を目的としたアプリケーションを指していることを理解しています。しかし、私の聴衆と発行者が同じものであることを私が理解している方法は、myserver.com来た人myserver.comが承認され認証されるようにトークンを発行することです。2つのクレームの違いはわかりませんが、1つあることは知っています。 で書かれた良い記事がありましたmsdn すべての予約済みのクレームで、発行者とオーディエンスが完全に異なっていたため、最も混乱しました。

2
クッキー対セッション対jwt
Webアプリケーションの認証/承認について読んでいます。誰かが私の現在の知識を確認/修正できますか? Cookie:初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報(ロールなど) セッション:一意のクライアントIDのみがファイル(Cookieとも呼ばれます)で送信され、それ以外はすべてサーバーに保存されます JWT:すべてがトークンに保存されます(これは、Cookieとも呼ばれるテキストファイルに保存することもできます) フィードバックをありがとう!

2
JWTのペイロードにアクセス許可とロールを含める必要がありますか?
クライアントの権限と役割に関する情報をJWTに含める必要がありますか? JWTトークンにそのような情報があると、有効なトークンが来るたびに非常に役立つため、ユーザーに関する権限に関する情報を抽出するのが簡単になり、データベースを呼び出す必要もありません。しかし、そのような情報を含め、データベースで同じことをダブルチェックしないことは、セキュリティの問題でしょうか? または、 上記のような情報はJWTの一部ではなく、データベースのみを使用してユーザーのアクセスロールとアクセス許可を確認する必要がありますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.