Qual è la differenza tra OpenID e SAML?

Qual è la differenza tra OpenID e SAML?

OpenID 2.0 originale vs SAML

Sono due diversi protocolli di autenticazione e differiscono a livello tecnico.

Da lontano, le differenze iniziano quando gli utenti avviano l'autenticazione. Con OpenID, un login utente è generalmente un indirizzo HTTP della risorsa responsabile dell'autenticazione. D'altra parte, SAML si basa su un trust esplicito tra il tuo sito e il provider di identità, quindi è piuttosto raro accettare credenziali da un sito sconosciuto.

Le identità OpenID sono facili da aggirare in rete. Come sviluppatore potresti quindi accettare utenti provenienti da provider OpenID molto diversi. D'altra parte, un provider SAML di solito deve essere codificato in anticipo e federare l'applicazione con solo provider di identità selezionati. È possibile restringere l'elenco dei provider di identità OpenID accettati, ma penso che ciò sarebbe contrario al concetto generale OpenID.

Con OpenID accetti le identità provenienti da server arbitrari. Qualcuno afferma di esserlo http://someopenid.provider.com/john.smith. Come abbinerai questo con un utente nel tuo database? In qualche modo, ad esempio memorizzando queste informazioni con un nuovo account e riconoscendole quando l'utente visita di nuovo il tuo sito. Nota che qualsiasi altra informazione sull'utente (incluso il suo nome o e-mail) non può essere considerata attendibile!

D'altra parte, se esiste una fiducia esplicita tra l'applicazione e il provider di ID SAML, è possibile ottenere informazioni complete sull'utente, inclusi il nome e l'e-mail, e queste informazioni possono essere attendibili, solo a causa della relazione di fiducia. Significa che tendi a credere che il provider di identità abbia in qualche modo convalidato tutte le informazioni e che ti puoi fidare a livello di applicazione. Se gli utenti vengono forniti con token SAML emessi da un provider sconosciuto, l'applicazione rifiuta l'autenticazione.

OpenID Connect vs SAML

(sezione aggiunta 07-2017, ampliata 08-2018)

Questa risposta risale al 2011 e all'epoca OpenID stava per OpenID 2.0 . Successivamente, da qualche parte nel 2012, è stato pubblicato OAuth2.0 e nel 2014 OpenID Connect (una sequenza temporale più dettagliata qui ).

Per chiunque legga questo al giorno d'oggi - OpenID Connect non è lo stesso OpenID a cui fa riferimento la risposta originale , piuttosto è un insieme di estensioni a OAuth2.0.

Mentre questa risposta può far luce sul punto di vista concettuale, una versione molto concisa per qualcuno che arriva con lo sfondo OAuth2.0 è che OpenID Connect è in realtà OAuth2.0 ma aggiunge un modo standard di interrogare le informazioni dell'utente , dopo il token di accesso è disponibile.

Facendo riferimento alla domanda originale - qual è la differenza principale tra OpenID Connect (OAuth2.0) e SAML è come viene costruita la relazione di fiducia tra l'applicazione e il provider di identità:

• SAML crea la relazione di fiducia su una firma digitale, i token SAML emessi dal provider di identità sono XML firmati, l'applicazione convalida la firma stessa e il certificato che presenta. Le informazioni dell'utente sono incluse in un token SAML, tra le altre informazioni.

• OAuth2 crea la relazione di trust su una chiamata HTTP diretta dall'applicazione all'identità. La richiesta contiene il token di accesso (ottenuto dall'applicazione durante il flusso del protocollo) e la risposta contiene le informazioni sull'utente.

• OpenID Connect espande ulteriormente questo per rendere possibile ottenere l'identità senza questo passaggio aggiuntivo che coinvolge la chiamata dall'applicazione al provider di identità. L'idea si basa sul fatto che i provider OpenID Connect in effetti rilasciano due token, lo access_tokenstesso OAuth2.0 e il nuovo, quello id_tokenche è un token JWT , firmato dal provider di identità. L'applicazione può utilizzare il id_tokenper stabilire una sessione locale, in base alle attestazioni incluse nel token JWT ma id_token non può essere utilizzata per interrogare ulteriormente altri servizi, tali chiamate a servizi di terze parti dovrebbero comunque utilizzare ilaccess_token. Puoi pensare a OpenID Connect come a un ibrido tra SAML2 (token firmato) e OAuth2 (token di accesso), poiché OpenID Connect coinvolge solo entrambi.

OpenID e SAML2 sono entrambi basati sullo stesso concetto di identità federata. Di seguito sono alcune delle differenze tra loro ..

1. SAML2 supporta la disconnessione singola, ma OpenID no
2. I provider di servizi SAML2 sono associati ai provider di identità SAML2, ma le parti che si affidano a OpenID non sono associate ai provider OpenID. OpenID ha un protocollo di rilevamento che rileva dinamicamente il corrispondente provider OpenID, una volta che viene fornito un OpenID. SAML ha un protocollo di rilevamento basato sul protocollo del servizio di rilevamento dei provider di identità.
3. Con SAML2, l'utente è accoppiato all'IdP SAML2: l'identificatore SAML2 è valido solo per l'IdP SAML2 che lo ha emesso. Ma con OpenID possiedi il tuo identificatore e puoi mapparlo a qualsiasi provider OpenID che desideri.
4. SAML2 ha diversi binding mentre l'unico binding che OpenID ha è HTTP
5. SAML2 può essere avviato come Service Provider (SP) o Identity Provider (IdP). Ma OpenID ha sempre avviato SP.
6. SAML 2 si basa su XML mentre OpenID no.
7. La maggior parte dell'applicazione sviluppata negli ultimi 3 anni supportava solo OpenID Connect.
8. Il 92% delle richieste di autenticazione 8B + fornite da Microsoft Azure AD nel maggio 2018 provenivano da applicazioni abilitate per OpenID Connect.

Mettendo da parte i dettagli tecnici, essendo piuttosto in ritardo per la festa, quello che capisco è che la più grande differenza tra SAML e altri standard di autenticazione (incluso OpenID) è che

SAML richiede che Identity Provider (IDP) e Service Provider (SP) si conoscano in anticipo, preconfigurati , autenticazione e autorizzazione statiche . OpenId (+ Connect) non ha tale requisito.

Questo è importante per gli IDP che desiderano il pieno controllo su chi accede ai dati. Parte dello standard è configurare ciò che viene fornito a SP specifici.

Ad esempio, una banca potrebbe non desiderare che i suoi utenti accedano a servizi diversi da quelli predefiniti (a causa di regolamenti o altre rigide regole di sicurezza).

Ciò non significa che un IDP OpenId non possa applicare tale limitazione. Un implementatore OpenID può controllare l'accesso, ma questo non è lo scopo di OpenID.

A parte la differenza di controllo di accesso predefinita, rigorosa, statica, concettualmente (non tecnicamente), OpenID Connect e SAML sono simili.

In conclusione, se sei un SP, dovresti supportare ciò che i tuoi clienti richiedono:

1. Se il tuo cliente è un singolo utente finale (ad esempio utilizzando il suo ID Google), dimentica SAML. Usa OpenID Connect.
2. Se il tuo cliente è una banca che desidera che i suoi dipendenti utilizzino il tuo servizio ed esportino solo un elenco statico di dati che fornirà al tuo servizio, la banca probabilmente vorrà che tu supporti SAML. La banca potrebbe avere un'implementazione OpenID con restrizione del cliente, che sarà il tuo giorno fortunato :)

Sia SAML che OpenID possono fungere da provider di identità (IdP abbreviato), ovvero protocollo di autenticazione decentralizzata (identità single sign-on).

L' S icurezza A ssertion M arkup L anguage ( SAML ) è un insieme di profili per lo scambio di dati di autenticazione e autorizzazione tra domini di sicurezza. Nel modello di dominio SAML, un provider di identità è un tipo speciale di autorità di autenticazione. In particolare, un provider di identità SAML è un'entità di sistema che emette asserzioni di autenticazione insieme a un profilo SSO di SAML. Una parte che fa affidamento su queste asserzioni di autenticazione è chiamata provider di servizi SAML. fonte

O pen ID C onnect ( OIDC ) è un livello di autenticazione su OAuth 2.0, un framework di autorizzazione. Lo standard è controllato dalla OpenID Foundation. OAuth è per protocollo di autorizzazione, piuttosto che un protocollo di autenticazione e OpenID specificamente progettato come protocollo di autenticazione. OIDC utilizza semplici token Web JSON (JWT), che sono più facili da utilizzare tramite JavaScript.

Scenario d'uso:

Usa OAuth se i tuoi utenti potrebbero semplicemente voler accedere con Facebook o Twitter. Usa OpenID se i tuoi utenti sono manubri che gestiscono i propri provider OpenID perché "non vogliono che qualcun altro possieda la propria identità".

fonte