Processo di autenticazione v0.6

SDK dell'App Directory

Processo di autenticazione (v0.6, deprecata)

La maggior parte delle app vuole fornire contenuti specifici per l'utente e capacità interattive. Prima di implementare l'autenticazione, la tua app non conosce l'utente Hootsuite che la sta utilizzando. Questa pagina descrive le tecniche per autenticare un utente Hootsuite con la tua app.

Tieni presente che queste tecniche NON forniscono metodi di autenticazione con service provider esterni. L'impostazione dell'autenticazione con un provider esterno è tua responsabilità e può essere effettuata con qualunque metodo di autenticazione supportato dal provider.

Per decidere quale tipo di autenticazione si adatta meglio ai tuoi bisogni, prendi in considerazione le seguenti caratteristiche:

  • Single Sign-On comunica a uno stream della tua app quale utente di Hootsuite la sta visualizzando, fornendo un ID utente. Lo spoofing di tale ID utente viene impedito con l'aiuto di un valore hash (token di sicurezza), autenticando in questo modo la richiesta.
  • OAuth si comporta analogamente a Single Sign-On, ma anziché passare un ID utente e un valore hash, passa un ID di sessione (token di sessione) che era stato precedentemente negoziato tra Hootsuite e la tua app. Oltre a tutto ciò, durante l'installazione della tua app, viene chiesto all'utente di accedere al suo account, che si trova nella tua base utenti, e tu dovrai archiviare il suo ID account, al fine di farlo corrispondere con il token di sessione quando visualizzi gli stream. L'ID account immesso viene quindi associato all'installazione della tua app.

Ne consegue che OAuth è utile se vuoi connettere un utente della tua base utenti alla tua app, ma presuppone anche che l'utente installi la tua app più volte, se vuole connettere più di un account. Indicheremo questa circostanza come una caratteristica per-App.

Puoi anche decidere di permettere a un utente di effettuare l'accesso a un qualunque altro account utente, che in seguito dovrai associare manualmente alla tua app utilizzando un'autenticazione Single Sign-On. Spetta solo a te decidere se vuoi connettere un account utente in questo modo. Puoi offrire account che si connettono dalla tua base utenti o implementare l'autenticazione con un service provider esterno (utilizzando qualunque metodo di autenticazione supportato dal provider). A prescindere dal metodo che sceglierai, li chiameremo account di terze parti per facilitare la comprensione di questo documento. Ora tieni a mente che: Se volessi associare un account di terze parti con la tua app con un metodo per-App, analogamente alla caratteristica OAuth descritta in precedenza, potresti causare dei problemi dovuti al fatto che un utente può aggiungere più volte stream alla tua app. In questo modo, per te sarebbe impossibile riportare lo stato di autenticazione attuale in ogni stream, quando un utente completa o annulla l'autenticazione del suo account di terze parti all'interno di uno degli stream. Per questo motivo, è generalmente consigliabile associare un account di terze parti con uno stream singolo. Indicheremo questa circostanza come una caratteristica per-Stream.

Anche questo tipo di autenticazione di account di terze parti per-Stream offre il vantaggio di permettere a un utente di connettere più account alla volta, ognuno nel suo stream, senza la necessità di installare la tua app più volte.

Uno dei parametri di URL passato agli stream è l'ID di posizionamento dello stream, chiamato pid. Questo parametro è univoco per ogni stream aggiunto dall'utente ed è utile quando si implementa l'autenticazione per-Stream di un account di terze parti.

Single Sign-On

Viene calcolato l'hash di un identificatore di utente, un timestamp e una chiave segreta (salt) condivisa tra Hootsuite e lo sviluppatore tramite SHA-1, quindi l'hash viene passato all'app. L'hash di verifica può essere ricalcolato dallo sviluppatore dell'app e confrontato con quello che è stato passato. Se corrispondono, si può dire che l'utente a cui fa riferimento l'identificatore ha effettuato l'accesso.

Utilizzando questo metodo, una terza parte non può effettuare lo spoofing di un hash di verifica senza conoscere la chiave segreta condivisa. Il metodo rimane comunque vulnerabile a un attacco replay effettuato da qualcuno in grado di intercettare il traffico di rete non criptato e visualizzare la stringa di query. Questo rischio può essere mitigato utilizzando https e controllando che il timestamp sia recente.

Per impostazione predefinita, l'identificatore utente fornito è un identificatore univoco legato all'account di Hootsuite dell'utente. In alternativa, puoi consentire all'utente di immettere un identificatore (indirizzo e-mail, nome utente, ecc) da passare alla tua app. Questo metodo, però, dovrebbe essere utilizzato solo se i dati visualizzati dalla tua app sono pubblici, visto che chiunque potrebbe immettere l'indirizzo e-mail di un altro utente.

Esempio di URL:

https://app.somewhere.com?i=1667985&ts=1310681657&token=231a3fb74139c74c37e9111ceb59ce02a349ef88

L'app convaliderebbe questi parametri in quanto tali:

$secret = 'sharedSecretABCD1234'; // defined in App configuration at hootsuite.com/developers
$user_id   = $_REQUEST['i'];
$timestamp = $_REQUEST['ts'];
$token     = $_REQUEST['token'];
if (sha1($user_id . $timestamp . $secret) == $token)
{
    echo "Accesso effettuato con successo!";
}

Parametri URL passati all'iframe dello stream dell'App:

lang=en
timezone=7200
pid=2823         // placement ID, unique for each stream per user
uid=1234567      // Hootsuite user ID
i=1234567        // user identifier (optionally entered by user upon App installation)
ts=1318362023    // timestamp
token=123abc...  // security token (sha1 hash)

OAuth

L'impostazione di un'autenticazione OAuth richiede una conoscenza approfondita dell'architettura OAuth, dato che è necessario implementare un endpoint per il "Service Provider" rispettando le specifiche di OAuth, come evidenziato dal diagramma sottostante. Anche se questo metodo richiede più tempo, rispetto all'autenticazione Single Sign-On, tra i vantaggi principali ci sono un livello maggiore di sicurezza e un'esperienza utente facilitata, visto che all'utente viene richiesto di effettuare l'accesso alla tua app quando la installa.

Hootsuite utilizza un'implementazione standard di OAuth, con l'aggiunta di un passaggio in più, durante il quale Hootsuite recupera un ID sessione dall'endpoint di autenticazione dell'app, utilizzando un fetch autenticato tramite OAuth. È necessario implementare tale endpoint di autenticazione in cima al "Service Provider" di OAuth.

Il diagramma di flusso sottostante evidenzia la procedura di autenticazione, a partire dal processo OAuth standard, che viene innescato quando un utente installa l'app, continuando con la convalida del token di accesso dall'endpoint di autenticazione, per finire con l'accesso dell'utente all'app.

hsOauth.45b015e3

Endpoint di autenticazione

La prima volta che un'app viene aperta, non viene passato alcun token di sessione, perché Hootsuite non ne ha ancora nessuno su file. A quel punto, l'app dovrebbe chiamare hsp.startAppTokenAuth() per innescare una richiesta di token di sessione dall'endpoint di autenticazione dell'app. Quando Hootsuite ha ricevuto il token, lo carica nuovamente dello stream dell'app, questa volta passando il token, che viene convalidato dall'app. Se è lo stesso fornito dall'endpoint di autenticazione, è ragionevole considerare l'utente come autenticato.

È anche possibile descrivere questo processo dicendo che il passaggio dello scambio di token utilizza OAuth per far accedere un utente al tuo sito. Tu generi un ID di sessione come faresti per ogni altra azione di accesso utente, ma lo passi a Hootsuite, che può inviarlo quando l'app viene caricata, in modo da identificare l'utente attualmente connesso.

Maggiori dettagli:

  • L'utente di Hootsuite carica lo stream dell'app, l'app viene caricata dal server del provider dell'app, non viene passata alcuna credenziale di autenticazione.
  • L'app nota che non c'è una sessione utente e che non è stata passata alcuna credenziale di autenticazione, visualizza il messaggio "Accesso in corso" e chiama hsp.startAppTokenAuth() javascript, il che dà inizio a uno scambio di token di sessione.
  • Viene effettuata una richiesta nel backend dai server di Hootsuite all'endpoint di autenticazione dell'app, il che verifica i token OAuth e restituisce un ID di sessione.
  • L'iframe dell'app viene caricato nuovamente, questa volta passando l'ID di sessione. L'app convalida l'ID di sessione e lo utilizza per iniziare una sessione utente.

Hootsuite continua a passare il token di sessione che ha su file ogni volta che lo stream di un'app viene caricato. Lo sviluppatore dell'app deve decidere per quanto tempo un token di sessione debba rimanere valido. Se la tua app considera una sessione scaduta o non valida per altri motivi, hsp.startAppTokenAuth() dovrebbe essere chiamato nuovamente per innescare la creazione di un nuovo token di sessione.

Convalida del token di accesso

L'endpoint di autenticazione dell'app dovrebbe convalidare un token di accesso come delineato nelle specifiche di OAuth e restituire una stringa convertita in formato JSON contenente un 'session_token':

echo json_encode(array('result'=>'success', 'session_token'=>'abcd1234'));

{"result":"success","session_token":"abcd1234"}

O, se il token non è stato convalidato:

{"result":"fail","reason":"Some error message"}

Se le credenziali passate all'endpoint di autenticazione non sono valide, l'app potrebbe chiedere a Hootsuite di aprire la finestra di dialogo "edit app" dell'utente utilizzando la chiamata di funzione hsp.editAppAuth(), che consente all'utente di Hootsuite di immettere nuove credenziali o riavviare il processo di OAuth.

Per un elenco di link a implementazioni di OAuth in molte lingue (molte delle quali comprendono codice che può essere utilizzato per creare un provider OAuth), dai uno sguardo a http://oauth.net/code/