Articles

Protocolli di autenticazione del sito web

I sistemi di autenticazione sono la spina dorsale di molti siti web. Permette agli utenti di accedere al tuo sito e di conservare i dati tra una visita e l’altra. È fondamentale per offrire un’esperienza utente robusta che ricompensi i tuoi utenti per aver fornito i loro dati. Le autenticazioni spesso forniscono l’accesso a dati personali privati che, se resi pubblici, potrebbero danneggiare l’utente. Per evitare ciò, i protocolli di autenticazione sono stati creati per proteggere le richieste mentre permettono agli utenti di accedere in modo sicuro al vostro sistema da qualsiasi ambiente.

Basic SSL Auth

Basic auth è la forma più semplice di autenticazione web. Utilizza intestazioni HTTP standard al posto di soluzioni più complicate che si basano su cookie, identificatori di sessione e pagine di login. C’è molta poca sicurezza incorporata nel sistema di autenticazione di base. Le credenziali sono trasmesse solo con la codifica Base64 e non sono crittografate o hash. A causa delle insicurezze radicate nel sistema, queste richieste sono più spesso fatte via HTTPS.

Le informazioni di autorizzazione dovrebbero essere compilate nel seguente formato e incluse nell’intestazione:

Formato:

<!--Authorization: Basic -->

I dettagli completi sul protocollo Basic Authentication possono essere trovati qui: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth funziona in modo simile all’autenticazione SSL di base con l’eccezione che la password è criptata usando un hash a senso unico. Utilizza l’hashing crittografico MD5 con un nonce (un valore generato dal server che previene gli attacchi replay).

Il tipico flusso di una richiesta Digest Auth è :

  1. Un utente naviga verso una pagina che richiede che l’utente sia autenticato.
  2. Il server risponde con un messaggio 401 che indica che un utente non è attualmente autorizzato ad accedere al contenuto. Nella risposta include anche il nonce che sarà utilizzato durante l’autorizzazione per prevenire attacchi di replay,
  3. Il sito visualizza quindi un’interfaccia di autenticazione al fine di raccogliere i dettagli richiesti (nome utente e password)
  4. I dettagli forniti sono reinviati al server con un’intestazione di autenticazione inclusa nella richiesta che ha un codice di risposta.
  5. Il server verificherà le credenziali fornite e accetterà l’autenticazione o restituirà un messaggio 401 se le credenziali non sono corrette, il che farà sì che all’utente venga nuovamente richiesta l’interfaccia di autenticazione.

Puoi trovare tutti i dettagli sul protocollo Digest Auth qui: https://www.ietf.org/rfc/rfc2617.txt

Outh 1.0

Il protocollo OAuth 1.0 si basa sull’avere un segreto condiviso tra il server e il sito. Questo segreto condiviso è usato per generare una firma che è inclusa nella richiesta. La firma generata è usata per verificare sul lato server la validità della richiesta di autenticazione. Il processo di autorizzazione dell’utente è generalmente gestito in tre fasi (3-legged OAuth):

  1. Il sito ottiene il Request Token.
  2. L’utente autorizza il Request Token.
  3. Il sito scambia il Request Token con Access Token.

Il processo di completamento di una richiesta OAuth a 3 gambe sarà generalmente gestito come segue:

  1. Il sito invierà una richiesta firmata per il Request token. Questa richiesta dovrebbe contenere i seguenti parametri:

    1. outh_consumer_key
    2. outh_timestamp
    3. outh_nonce
    4. outh_signature
    5. outh_signature_method
    6. outh_version
    7. outh_callback

Questa richiesta sarà convalidata sul server e se convalidata restituirà il token di richiesta nel seguente formato:

  1. outh_token
  2. outh_token_secret
  3. e qualsiasi altro parametro aggiuntivo restituito dal server.
  4. Il passo successivo al recupero del token di richiesta è quello di chiedere all’utente di inserire le proprie credenziali di accesso. Queste sono poi formattate in una firma con il token di richiesta oauth_token e inviate con una richiesta al server per la convalida. Se la convalida di questa richiesta ha successo, il server restituirà quanto segue:
  5. oauth_token
  6. outh_verifier

Questi saranno usati nel passo successivo per recuperare un token di accesso.

  1. Il passo finale è lo scambio dei dettagli recuperati dal passo 2 con un token di accesso, che sarà usato per accedere alle risorse del server. Per scambiare il tuo token di richiesta con un token di accesso, puoi fare una richiesta al server con la seguente richiesta firmata
  2. oauth_token – restituito dal passo 2
  3. oauth_consumer_key
  4. outh_nonce
  5. outh_signature
  6. outh_signature_method
  7. auth_version
  8. outh_verifier -restituito dal passo 2

Questo ti restituirà un token di accesso da usare insieme al tuo segreto per fare richieste di informazioni dal server.

Puoi trovare tutti i dettagli sul protocollo OAuth 1.0 qui: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Questo è simile al protocollo OAuth 1.0, si basa su un id e un segreto del client per formattare la richiesta, ma semplifica molto del complicato processo di firma che è inerente al sistema OAuth 1.0. Il processo per autorizzare un utente usando il protocollo OAuth 2.0 a 3 gambe è il seguente0 è il seguente:

  1. L’utente è diretto al servizio per l’autorizzazione con i seguenti dettagli inclusi nell’URL di autorizzazione:

    1. client_id
    2. redirect_uri
    3. response_type
    4. scope
  2. L’utente si autentica con il servizio e garantisce all’applicazione l’accesso ai suoi dati. Se l’autenticazione ha successo, l’utente viene reindirizzato al redirect_uri con i seguenti parametri:

    1. code
    2. state
  3. Il codice restituito nel passo 2 viene poi usato dall’applicazione per fare una richiesta di un token di accesso. Incluso in questa richiesta dovrebbe essere:

    1. client_id
    2. client_secret
    3. code
    4. redirect_uri
    5. grant_type – Questo dovrebbe essere impostato su “authorization_code”

Il server verifica questi dettagli e poi restituisce un token di accesso con una scadenza se sono validi. Questi sono generalmente restituiti nel seguente formato:

  1. access_token
  2. expires_in
  3. refresh_token

Puoi trovare dettagli completi sul protocollo OAuth 2.0 qui: http://oauth.net/2/

I protocolli di autenticazione ti permettono di proteggere i tuoi dati con diversi livelli di sicurezza. A seconda dei dati a cui si accede e del livello di sicurezza desiderato, l’implementazione di uno dei protocolli di cui sopra vi permette di essere sicuri che i vostri dati siano al sicuro e che vi accedano solo gli utenti autorizzati al vostro sistema.