Il fulcro dell’autenticazione Single Sign-On è una tecnologia chiamata JSON Web Token (JWT) che consente a Zendesk di considerare attendibili le richieste di accesso ricevute dai sistemi. Per dettagli, consultaConfigurazione di Single Sign-On con JWT (JSON Web Token) .
Ecco come appare una richiesta di autenticazione con token web JSON:
https://joeandco.zendesk.com/access/jwt?jwt=eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9.eyJpYXQiOjEzNzIxMTMzMDUsImp0aSI6ODg4MzM2MjUzMTE5Ni4zMjYsIm5hbWUiOiJUZXN0IFVzZXIiLCJlbWFpbCI6InR1c2VyQGV4YW1wbGUub3JnIiwiZXh0ZXJuYWxfaWQiOiI1Njc4Iiwib3JnYW5pemF0aW9uIjoiQXBwbGUiLCJ0YWdzIjoidmlwX3VzZXIiLCJyZW1vdGVfcGhvdG9fdXJsIjoiaHR0cDovL21pdC56ZW5mcy5jb20vMjA2LzIwMTEvMDUvQmFybmFieV9NYXR0X2Nyb3BwZWQuanBnIiwibG9jYWxlX2lkIjoiOCJ9.Zv9P7PNIcgHfxZaMwQtMpty3TZnmVHRWcsmAMM-mNHg
Inserendo l’opzione nella barra degli URL in un browser, ho effettuato l’accesso a un’istanza Zendesk.
È semplicissimo. Nient’altro è necessario. Nessun server che parla tra loro fuori vista. Tutto avviene in un URL.
Uno script di autenticazione remota deve semplicemente compilarlo (beh, qualcosa del genere) e indirizzare l'utente a quella destinazione.
Analizziamo il token in dettaglio.
https://joeandco.zendesk.com/access/jwt?jwt=
Il primo bit è un endpoint URL a cui indirizzare le richieste di autenticazione remota. È seguito da un punto interrogativo (?), che indica che stai aggiungendo dei parametri. I parametri trasmettono alcune informazioni allo script nell’endpoint di destinazione (https://joeandco.zendesk.com/access/jwt). Lo script deve essere progettato in modo da accettare questi parametri, motivo per cui è necessario inviarlo a /access/jwt e non solo a un indirizzo casuale.
Dopo il punto interrogativo, “jwt” è il nome del parametro e “=” indica che la stringa che segue è il valore del parametro.
Il resto sono dati. Se osservi attentamente, noterai che è diviso in blocchi in base a punti (punti). Esamineremo ogni blocco uno alla volta.
Blocco 1: Intestazione JWT
Il primo blocco è l’intestazione JWT. Indica che si tratta di una richiesta JWT e indica il tipo di algoritmo di hashing usato. (Ne parleremo più avanti.)
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
La grande rivelazione di questo (e del resto dei dati) è che sono codificati in base64. In realtà non si tratta di crittografia, quindi può essere facilmente decodificata da strumenti come i seguenti:
- Strumento web:http://www.base64decode.org/
- Terminale:http://drewsymo.com/how-to/quick-and-simple-base64-encode-on-mac-osx-terminal/
Ecco come appare la stringa decodificata:
{"typ":"JWT",
"alg":"HS256"}
Come puoi vedere, richiede una struttura JSON e ha due coppie chiave-valore che in effetti significano type: JWT
e Algorithm: HMAC SHA 256
. SHA 256 è un algoritmo di crittografia a 256 bit progettato dagli Stati Uniti NSA (National Security Agency, Agenzia per la Sicurezza Nazionale degli Stati Uniti) Viene usato per generare il terzo blocco, la firma, di cui parleremo tra breve.
Blocco 2: Insiemi di attestazioni JWT/Carico utile
Il secondo blocco è considerevolmente più lungo perché contiene il payload. È noto come “Set di attestazioni JWT”.
eyJpYXQiOjEzNzIxMTMzMDUsImp0aSI6ODg4MzM2MjUzMTE5Ni4zMjYsIm5hbWUiOiJUZXN0IFVzZXIiLCJlbWFpbCI6InR1c2VyQGV4YW1wbGUub3JnIiwiZXh0ZXJuYWxfaWQiOiI1Njc4Iiwib3JnYW5pemF0aW9uIjoiQXBwbGUiLCJ0YWdzIjoidmlwX3VzZXIiLCJyZW1vdGVfcGhvdG9fdXJsIjoiaHR0cDovL21pdC56ZW5mcy5jb20vMjA2LzIwMTEvMDUvQmFybmFieV9NYXR0X2Nyb3BwZWQuanBnIiwibG9jYWxlX2lkIjoiOCJ9
Contiene una data/ora, un valore casuale, un nome utente, un indirizzo email, un ID esterno e alcuni tag. Ci sono ancora più opzioni disponibili. Ancora una volta, basta decodificarlo in base64 per dare un senso al payload. Divido le linee per semplificare la digestione.
{
"iat":1372113305,
"jti":8883362531196.326,
"name":"Test User",
"email":"tuser@example.org",
"external_id":"5678",
"organization":"Apple",
"tags":"vip_user",
"remote_photo_url":"http://mit.zenfs.com/206/2011/05/Barnaby_Matt_cropped.jpg",
"locale_id":"8"
}
Obbligatorio
IAT
La prima chiave èiat, che sta peremesso alle. Si tratta di un timestamp formattato in secondi interi a partire dal 1 gennaio 1970, che è una rappresentazione UNIX standard del tempo. Il timestamp deve essere un numero intero (senza decimali) e il formato UTC. Inoltre, deve essere entro 3 minuti dall’ora corrente in cui il server Zendesk lo riceve. In questo modo, ogni richiesta di autenticazione remota si autodistrugge, impedendo che ogni singola richiesta venga usata più di 3 minuti dopo la generazione.
JTI
La seconda chiave,jti, sta perJSON Token ID. In realtà è solo una stringa casuale. Deve essere sufficientemente lungo e casuale in modo da non poter essere usato di nuovo su questo account. Se, per errore, viene riutilizzato per un'altra richiesta di autenticazione, la richiesta non avrà esito positivo. Ciò che equivale a una chiave usa e getta. Includendo un valore casuale (obbligatorio) come questo, garantiamo che non esistano due richieste di autenticazione uguali. Ciò impedisce il riutilizzo di un URL di richiesta valido. Ad esempio, immagina che qualcuno sia riuscito a installare malware sul tuo computer o sulla tua rete e abbia iniziato a registrare il tuo traffico. Possono vedere tutti gli URL che trovi. Se vedono e afferrano l’URL che ti è stato fornito per accedere a Zendesk, potrebbero usarlo per accedere come te entro 3 minuti senza questa chiave monouso.
Nome
Il prossimo è ilnomecompleto dell’utente (spazi inclusi). Qualunque cosa Zendesk riceva qui viene impostato come nome utente, anche se in precedenza era stato impostato un nome diverso.
Dopo c’è l’indirizzo email dell’utente. Viene usato come identificatore univoco per un utente, ameno che non venga ricevuto un ID esterno*. Ciò significa che se riceviamo un’email e un ID esterno, cerchiamo prima di abbinare l’ID. In caso contrario, aggiorniamo l’utente con l’indirizzo email specificato.
*Nota: Se l’opzione “Consenti aggiornamento di ID esterni” è abilitata in Zendesk, continueremo a disattivare l’email anche se viene ricevuto un ID esterno. Se l’indirizzo email e l’ID esterno differiscono, cambieremo l’ID.
Opzionale
ID esterno
L’ID esterno è un ID facoltativo che puoi usare per identificare gli utenti anziché usare il loro indirizzo email (come indicato sopra).
Organizzazione
Puoi anche passare un valore diorganizzazioneper aggiungere un utente a un’organizzazione. L’organizzazione indicata deve esistere già e il nome deve corrispondere esattamente. Altrimenti non verrà intrapresa alcuna azione.
Tag
La chiave tagpermette di impostare i tag sull’utente che ha effettuato l’accesso. La chiave sostituisce tutti i tag esistenti nell’utente con i tag specificati, quindi usala con attenzione. Il passaggio di un parametro tags vuotorimuove tutti i tag da un utente.
URL foto remota
Puoi anche passare un valore per remote_photo_url, che accetta un URL pubblico contenente una foto e imposta questa foto come immagine del profilo dell’utente.
Impostazioni locali (lingua)
Puoi passare un valore perlocale_id per impostare o aggiornare la lingua dell’utente autenticato in Zendesk. Il valore deve essere un numero che corrisponde a una delle impostazioni locali attualmente attive in Zendesk. Puoi trovare le impostazioni locali usando l’endpoint locales.json della nostra API: https://developer.zendesk.com/api-reference/ticketing/account-configuration/locales/#list-locales
Campi utente (non mostrati nell’esempio)
Deve essere un oggetto JSON che include coppie chiave-valore per ogni chiave e valore di campo. La chiave del campo può essere trovata o definita nell’interfaccia Campi utente. Tieni presente che possono essere inoltrati solo i campi utente personalizzati.
Esempio:
"user_fields": {"checked": false,"date_joined": "2013-08-14T00:00:00+00:00","region": "EMEA","text_field": null}
Le caselle di spunta usano valori booleani, i codici data seguono l’esempio qui sopra e i menu a discesa accettano il nome dell’opzione. I campi di testo accettano stringhe.
Numero di telefono (non mostrato nell’esempio)
Accetta una stringa come identità di un numero di telefono. Assicurati di specificare il numero di telefono in un formato accettato. Per maggiori informazioni, consultaQuali sono i formati accettati per i numeri di telefono?
Blocco 3: Firma JWS
L’ultima parte della richiesta è la parte crittografata. Non devi preoccuparti troppo di questo, ma in pratica prende tutte le informazioni sopra (iat, jti, nome, email, ecc.) Insieme alsegreto condivisoe genera una stringa crittografata. Quindi, in base agli standard JWT, viene presa una parte di quella stringa crittografata (nota come checksum), ovvero la firma JWS.
In che modo è sicuro?
Per generare una stringa crittografata valida, è necessario conoscere ilsegreto condiviso.
La crittografia è progettata in modo da non poter tornare indietro dalla stringa crittografata ai dati e alla chiave. Anche se si dispone del contenuto dei dati, è praticamente impossibile dedurre la chiave.
Ma dal momento che tu hai la chiave, e noi la chiave, e tu ci invii non crittografati gli stessi dati non crittografati, possiamo creare noi stessi la firma e verificare che corrisponda a quanto inviato.
Inoltre, garantisce che nessuno possa manomettere i dati in transito.
Ecco come compilarlo in pseudo-codice:
URLBase64Encode(
HMAC-SHA256(
URLBase64Encode( header_json ).URLBase64Encode( payload_json )
)
)
Quando si genera il codice HMAC-SHA256 dell’intestazione codificata e del payload, viene incluso il segreto condiviso.
Questo è il risultato:
Zv9P7PNIcgHfxZaMwQtMpty3TZnmVHRWcsmAMM-mNHg
Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.
Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.