SAML2 срещу JWT: Сравнение

Ключалка и ключ / Кайл Пиърсън

Тази публикация приключва нашата дискусия за SAML2 и JWT. Тук разглеждаме сравнение на характеристиките и случаите на използване на двете технологии. Трудно е да се направи пряко сравнение на JWT и SAML2. Както видяхме през тази поредица, трябва да се вземат предвид спецификациите, които работят във връзка с тези спецификации.

За JWT трябва да вземем предвид:

  • Семейство спецификации на OAuth2
  • Семейство от спецификации на OpenID Connect
  • JWE
  • да оказват

За SAML2 трябва да помислим

  • Семейство спецификации SAML2
  • XML цифров подпис
  • XML криптиране
  • WS-Security
  • WS-Trust

По-долу са обобщени основните разлики между SAML2 и JWT. Първоначалната версия на тази публикация използва формат на таблицата, но Medium.com не поддържа таблици.

възраст

SAML2: SAML 1.0, въведена през 2002 г .; SAML2, представен през 2005 г.

JWT: JWT RFC публикувана през 2014 г. JWT е много по-нова.

осиновяване

SAML2: SAML2 е стандартният стандарт за Enterprise SSO. Това е известно време.

JWT: JWT, OAuth2 и OpenID Connect са често срещани в стартиращите програми за социални медии и технологии, но едва сега намират своя път в предприятието.

Философия

SAML2: По-академичен подход. Простотата не беше цел на дизайна. Имаше предположение, че библиотеките по време на изпълнение ще бъдат разработени за реализиране на тази функционалност.

JWT: Просто. Започна с предположението, че разработчикът на приложения ще внедри кода от страна на клиента. С настъпването на спецификациите и настъпването на предприятието, общността започна да се отдалечава от това.

Видове жетони

SAML2: Утвърждаване на SAML (формат, строго определен от спецификациите)

OAuth2: access_token (може да бъде JWT, но не е необходимо)

OIDC: access_token (може да бъде JWT) и id-токен (трябва да е JWT).

Структура на данни

SAML2: XML (структура, дефинирана с XSD)

JWT: JSON (интересното е, че структурата НЕ е дефинирана от JSON Schema)

размер

SAML2: Обикновено е много голям в сравнение с JWT. Размерът варира в зависимост от наличните полета, използването на подписи и шифроване.

JWT: Много по-малки от маркери SAML2. Spec насърчава използването на позоваване на сертификата за подпис, а не вграждането му - елиминира голям хертоид подписващ x509.

Поддържащи протоколи за съобщения

SAML2: Основно на базата на SOAP.

JWT: REST API

Свързващи и транспортни протоколи

SAML2: SAML2 може да бъде HTTP POST, HTTP GET, SOAP (зависи от сценария), JMS (рядко, но може да се случи) и т.н.

JWT: HTTPS

Цифрови подписи

SAML2: XML подпис

JWT: JWS (поддържаните алгоритми за хеширане и криптиране се различават леко)

Шифроване на ниво съобщение

SAML2: XML криптиране

JWT: JWE (поддържаните алгоритми за криптиране се различават леко) ***

X509 Представяне на сертификат

SAML2: X509BinarySecurityToken тип

JWT: Спецификация на уеб ключа JSON (JWK)

Обхват на основните спецификации

SAML2: Дефинира структурата на маркера (SAML Assertion) и базовия протокол (за SSO на Web App).

JWT: JWT дефинира само структурата на маркера. OAuth2 и OpenID Connect определят протокола.

Клиентска инфраструктура

SAML2: Обикновено изисква поддържащи библиотеки (с голяма тежест)

JWT: Често може да се реализира чрез конструиране на обикновена HTTP заявка. Подписите и шифроването ще бъдат изключения от това правило. *

Поддръжка на метод за потвърждение на предмета

SAML2: SAML2 поддържа носителски маркери, притежател на ключ и ваучери за подаване.

JWT: JWT първоначално поддържаше носещи токени. Притежател на ключ (Доказателство за подкрепа за притежание е добавено през април 2016 г.).

Делегиране и представителство (OnBehalfOf и ActAs)

SAML2: Дефиниран в спецификацията на WS-Trust

JWT: Спецификация за разширение на OAuth2 (OAuth2 Token Exchange Spec)

Поддръжка за динамични актуализации на доверителен магазин и публикуване на метаданни.

SAML2: Спецификацията на WS-федерацията определя как тази информация може да бъде публикувана. Но той не се използва универсално. Рядко се случва клиентите динамично да извличат информация, публикувана от IdP, за да актуализират своя доверителен магазин на подписващия сертификат.

JWT: OpenID Connect Discovery спецификация определя крайната точка на метаданните, която публикува метаданни IdP. Силно се насърчава да се създават клиенти, които да имат достъп до тази информация и динамично да изграждат / актуализират доверието. **

* Използването на библиотеки е почти винаги препоръчително при изграждане на заявки / заявки от нулата.

** Този един детайл потенциално може да спести 1000 хиляди човешки часа, когато сертификатът за подписване трябва да бъде подновен.

*** Шифроването на JWE и XML ще има и редица уместни разлики, но все още не съм стигнал до тази серия :).

Всички разлики, очертани в серията XML DSig спрямо JSON Web Signature, се прилагат и тук.

Изображение: Lock & Key / Kyle Pearson