SAMLおよびKerberos認証モデルでは、どの認証局がユーザーを認証し、ダウンストリームシステムによって信頼されるように資格情報を発行したかを明示的に理解しています。 IDを伝達する目的で、ユーザーを偽装するダウンストリームシステムの権限は、ソリューションアーキテクチャおよび関連するIDドメイン内で厳密に制御できます。
私の知る限り、SAMLモデルとKerberosモデルの完全性はJWTアプローチの一部ではありません。 JWTは、Kerberosとよく似た機能を提供するメカニズムのようですが、定義されたKDEのサポート機能はありません。
何か不足していますか? JWTは「信頼の網」に基づいていますか、それとも各JWT実装は独自の信頼できる認証メカニズムなどを定義する責任がありますか?
したがって、JWTは単なるトークンです。プロトコルではありません。そのため、SAMLプロトコルをJWTと比較することはできません。これは、リンゴをアヒルと比較するようなものです。
JWTは、暗号化キーによって署名された一連の識別情報です。実際に入れるのはプロトコル次第です。 JWTを発行者やオーディエンス情報などのJWSオブジェクトと区別する正式な要件がいくつかありますが、その情報は任意です。比較すると、SAMLトークンとKerberosチケットは少し構造が異なりますが、同じ情報をJWTに追加できないとは限りません。
一方、プロトコルは比較するのが少し難しいです。
一般的に考えられている2つのプロトコルは、OAuth2とOpenID Connectです。どちらもJWTをトークンとして使用できます。 OAuth2は認証メカニズムとしてJWTを使用することがよくあります。JWTの存在とJWT内のクレームによって、保護されたリソースに対して呼び出し元がどのような権限を持つかが決まります。ユーザーの識別とは関係ありません。逆に、WS-Federationのようなプロトコルは、デフォルトでユーザーに関する識別情報を提供するためにSAMLトークンを使用しますbutは、(すべての関係者が形式を理解している限り)ドロップイン置換としてJWTを使用できます。 JWT本体への同じ情報。