Alla ricerca di pro / contro sull'utilizzo di OWIN rispetto a un'autenticazione basata su token semplice a mano

0

Vogliamo implementare un'API da utilizzare internamente ed esternamente e aggiungerla alle nostre soluzioni.

Alcune note sull'ambiente:

Attualmente utilizziamo VS2013, .Net 4.5, EF5, SQL2008, MVC4, C # e l'appartenenza a asp.net.

Abbiamo esaminato l'utilizzo del nuovo modello Web Api 2.2 fornito con VS2015 che utilizza OWIN.

Questo sembrava essere abbastanza esagerato per ciò di cui avevamo bisogno, così ho deciso di pubblicare la mia semplice autenticazione basata su token.

Gli unici requisiti rigidi erano che fosse basato su token e per accedere è necessaria solo una "chiave" API.

Quindi la prima chiamata è una GET al metodo di accesso in cui passerai nella tua chiave API

/Login/Login?apikey=12345678

Questo genererà quindi un token basato sul tuo IP, apiKey e timestamp.

    private static string GenerateTokenHash(string apiKey)
    {
        var encoding = new System.Text.ASCIIEncoding();
        byte[] keyByte = encoding.GetBytes(apiKey);
        byte[] messageBytes = encoding.GetBytes(GetIP4Address() + DateTime.Now.ToString());

        HMACSHA256 sha = new HMACSHA256(keyByte);
        var hash = sha.ComputeHash(messageBytes);
        return Convert.ToBase64String(hash);
    }

Quindi memorizzo questi token registrati in un dizionario statico per tenere traccia di quali token sono validi invece di memorizzarli in un DB.

L'utente finale api passa quindi questo token alle richieste successive utilizzando una nuova intestazione http denominata auth_token.

Creo anche un AuthorizationFilterAttribute per determinare quali azioni / controllori devono controllare per un token valido.

    public override void OnAuthorization(HttpActionContext actionContext)
    {
        base.OnAuthorization(actionContext);

        // No auth_token header sent
        if (!actionContext.Request.Headers.Contains(_httpTokenHeaderName))
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Unauthorized);
            return;
        }

        // Token is not valid
        var token = actionContext.Request.Headers.GetValues(_httpTokenHeaderName).FirstOrDefault();
        if (!TokenManager.ValidateToken(token))
        {
            actionContext.Response = new HttpResponseMessage(System.Net.HttpStatusCode.Unauthorized);
            return;
        }

        // Token is valid, extend expiration.
        TokenManager.ExtendExpiration(token);
    }

Questo sembra adattarsi alle nostre esigenze, ma mi piacerebbe eseguire il backup del perché.

OWIN sembra essere molto gonfia dato che non avremo mai bisogno di disaccoppiare il nostro back-end da sql, o di avere qualcuno autenticato via Facebook.

Sto solo cercando alcuni pro / contro su ogni implementazione che immagino.

    
posta user3953989 19.04.2016 - 18:56
fonte

1 risposta

2

Un paio di cose dopo un rapido sguardo:

  1. Il ricaricamento del dominio delle app sul server cancella il dizionario dei token e causa la disconnessione dei client. Inoltre, non è possibile ridimensionarlo in modo efficace su macchine diverse / carico bilanciato.

  2. Accedi tramite GET piuttosto che con un POST. In generale, non è consigliabile inviare informazioni sensibili tramite GET (viene memorizzato nei log del server, può essere memorizzato nella cache, ecc.)

  3. Se ti imbatti in un problema in cui il tuo nome utente è compromesso, devi cambiare il nome utente.

Se hai utilizzato il nome utente per inserire altri elementi (ad esempio ruoli), devi aggiornarli per adattarli.

Se hai username / password, tutto ciò che devi fare è cambiare la password - il nome utente rimane lo stesso.

Inoltre, non mostri il codice, ma devi fare attenzione che la memorizzazione dei token nel dizionario sia correttamente sicura.

    
risposta data 21.04.2017 - 18:01
fonte

Leggi altre domande sui tag