In che modo i formati token STS sono comparabili tra loro SAML vs SWT vs JWT?

Meglio o peggio è relativo all'utilizzo del protocollo. SAML ha il suo posto e SWT / JWT / et al hanno il loro posto. Le specifiche SAML sono praticamente scolpite nella pietra, mentre SWT / JWT sono ancora nella loro infanzia e continuano a cambiare.

SAML ha molte manopole che lo rendono piuttosto complesso e questo è il nemico di una buona sicurezza, ma tutti lo implementano allo stesso modo. SWT / JWT sono abbastanza semplici nel design, ma nessuno può essere d'accordo su un singolo standard di implementazione insanguinato e molte delle librerie pubbliche utilizzate non subiscono la revisione della sicurezza.

Dipende anche da come sono firmati i token e da come sono protette le chiavi utilizzate per la firma. I segreti condivisi tendono ad essere più difficili da proteggere e PKI è un PITA, ma altri potrebbero non essere d'accordo.

Dal punto di vista della sicurezza, non c'è molta differenza tra le specifiche del token SAM e JWT; si riduce in gran parte agli algoritmi di firma e crittografia supportati (JWT è più limitato a questo proposito, vedi link ).

Per questo caso d'uso, alla fine entrambi forniscono solo reclami (con tutto il bagaglio necessario, come i tempi di scadenza, il pubblico ecc.). TUTTAVIA, il sito collegato afferma che l'implementazione di JWT da parte di ACS non supporta la crittografia e potrebbe quindi essere "meno" sicura. Questo ovviamente dipende dal tuo caso d'uso effettivo.

Lo stesso vale per i token SWT, che non supportano affatto la crittografia. Ma questo potrebbe non essere un problema, poiché i token possono essere trasmessi su un canale sicuro che fornisce riservatezza (ad esempio HTTPS).

E da un punto di vista non di sicurezza nota che potrebbe esserci una differenza di prestazioni non trascurabili (in genere SAML che mette a dura prova le tue risorse).

Alla fine della giornata non penso che importi davvero, dal momento che è una preferenza per il formato. SAML 2.0 è impostato in pietra ma è molto grande e dettagliato (come tende ad essere XML). Ma nella mia preferenza personale in questi giorni con i miei progetti. Dico prova i token JWT , che è un token in formato JSON. Se le tue applicazioni client si estendono su piattaforme diverse, potrebbe essere molto più semplice guardare e gestire un oggetto JSON.

Le mie applicazioni client sono

• Applicazione Pure AngularJS
• App per iPad e iPhone per iOS
• App di Windows 8
• App per Android

Ed è protetto da un'API Web che accetta token di intestazione di autorizzazione con tutti i payload in formato JSON, quindi JWT sembrava una scelta logica per me . Quando sei completamente in. NET, per la semplicità di tutto basta usare un token SAML.

Quando ti spacciano clandestinamente al di fuori del puro Microsoft World: ti consiglio vivamente di usare JSON come formato su qualsiasi altro disponibile. JSON è il formato del web moderno in questi giorni quindi sei praticamente garantito anche quello.

Mi rendo conto che questa è una vecchia domanda e non sono un esperto di sicurezza in alcun modo. Tuttavia, la mia esperienza con Azure ACS e tipi di token mi ha portato a tre conclusioni:

1. SAML ha funzionato più o meno immediatamente. Il JWT era molto più laborioso e dovevo affidarmi ai blog per farlo funzionare.
2. La dimensione dei cookie era equivalente tra SAML e JWT. La mia app demo ha superato ~ 30 richieste; Non ho visto nulla che giustificasse l'affermazione secondo cui il JWT è molto più leggero del SAML.
3. Il plug-in Visual Studio di Identity and Access ha fornito un mezzo per configurare un servizio token di sicurezza locale potenzialmente utilizzabile per simulare i token in fase di sviluppo. JWT non era un'opzione in questo strumento.

Quindi sono andato con SAML.