Autenticazione di stato nell'API REST mediante token

Naviga le tue risposte
1

Recentemente ho iniziato un progetto che coinvolge un'API REST. L'API richiede l'autenticazione con i requisiti per consentire agli amministratori di visualizzare gli utenti registrati e di revocare immediatamente sessioni di accesso specifiche. L'API viene utilizzata principalmente da una SPA e un'applicazione nativa.

Durante la mia ricerca di implementazioni esistenti in ASP.NET Core 2x ho comunque qualche problema. Sembra che ci siano 4 metodi principali di autenticazione:

  1. Cookie-based
  2. Token Web JSON
  3. OAuth 1 e 2
  4. Servizi di terze parti come Microsoft, Google, Twitter ecc.

A causa dell'utilizzo dell'API da parte di un'autenticazione nativa, l'autenticazione basata su cookie non è valida. Non è richiesto l'integrazione con terze parti (come Google), quindi non è nemmeno un'opzione. Allo stesso modo, non vi è alcun obbligo per l'API di essere utilizzato da un numero sconosciuto di applicazioni di terze parti, che effettivamente esclude OAuth.

Ora mi mancano i token Web JSON, ma ... Hanno anche problemi. Soprattutto il requisito della revoca immediata degli accessi è importante, tuttavia non è possibile quando si utilizzano i JWT. Una possibile soluzione è il mantenimento di un elenco di revoche, ma che sconfigge la loro natura senza stato poiché ogni richiesta all'API dovrebbe controllare questo elenco. Ma poiché questa non è un'applicazione su larga scala, la funzione senza stato non ha importanza al momento. Non posso usare i token con una breve durata in quanto il requisito per la revoca immediata non funziona bene con questo. Ecco un articolo , che spiega perfettamente i miei problemi con i JWT come sessioni.

Quindi ora siamo al grande problema. Non ci sono soluzioni supportate già disponibili in ASP.NET Core disponibili.

Domanda 1: eventuali alternative o osservazioni dei problemi citati in precedenza, che potrebbero modificare la conclusione?

Ho cercato il vasto spazio che è internet per qualsiasi cosa, che soddisfi i requisiti, ma non è in grado di trovare altro, ma JWT e OAuth ... Tutti usano JWT per tutto ciò che sembra. Quindi questo mi ha portato a ciò che temevo: ho bisogno di scrivere la mia implementazione :(

La soluzione ottimale sarebbe:

  1. Il client scambia nome utente / password per un token casuale
  2. Il client invia il token nell'intestazione HTTP Authorization molto simile a JWT.
  3. Il token viene utilizzato per recuperare AuthenticationTicket dell'utente su una richiesta in entrata e il token è verificato.
  4. Disconnessioni o revoche rimuove il token (ed efficacemente AuthenticationTicket ) in un archivio centralizzato

Ricerca del codice sorgente per le soluzioni esistenti per l'autenticazione JWT e cookie principalmente in ASP.NET Core Mi rendo conto che posso riutilizzare un bel po 'delle implementazioni esistenti e integrarmi bene con il framwork, ma preferirei evitare di scrivere qualcosa di relativo alla sicurezza.

Domanda 2: qualcuno conosce un'implementazione che soddisfa questo flusso o può essere configurato per

Come nota conclusiva. So che archiviare lo stato della sessione lato server è contrario ai principi REST puri, ma lo trovo molto più pratico, visti i requisiti. Per superare eventuali problemi di ridimensionamento su un numero limitato di contenitori, prevedo di utilizzare un server centralizzato (come esempio) come cache / storage, che dovrebbe essere più che sufficiente a gestire il traffico previsto più volte.

    
posta AnotherGuy 28.07.2018 - 21:54
fonte

2 risposte

1

Question 1: Any alternatives or remarks of the previously mentioned issues, which would change the conclusion?

I cookie sono solo delle intestazioni, il tuo client nativo può aggiungerle e leggerle senza problemi. Non sono sicuro che la soluzione integrata consenta la revoca.

JWT / OAuth Il motivo della revoca non è supportato è quello di consentire di pensare che le risorse possono validare la richiesta senza contattare un server centrale. Evitando quel collo di bottiglia

Tuttavia! qualsiasi soluzione con revoca immediata richiede di essere convalidato su un server centrale.

L'implementazione di questo controllo extra è semplice. ad es. con IdentityModel nuget 

public class MyJwtSecurityTokenHandler : System.IdentityModel.Tokens.Jwt.JwtSecurityTokenHandler
{
    public override ClaimsPrincipal ValidateToken(string token, TokenValidationParameters validationParameters, out SecurityToken validatedToken)
    {
       return  myAuthService.ValidateToken(token, validationParameters, out validatedToken);
    }
}

Il server di autenticazione può tenere traccia dei token emessi, esporre un endpoint di revoca e un endpoint di LoggedInUsers. Proprio come il vecchio MembershipProvider ...

Question 2: Anyone know an implementation, which satisfies this flow or can be configured to?

Vuoi una soluzione pronta per l'uso, MembershipProvider e ottenere il tuo client nativo per capire i cookie è probabilmente il più vicino che otterrai. Potresti optare per l'opzione Cookieless, ma avere il token nell'URL è considerato meno sicuro e probabilmente è comunque difficile da gestire sul client.

Ma con .net Core, non sono sicuro che soddisfi tutti i tuoi obiettivi, e sicuramente sta nuotando contro la marea dei token JWT con crediti.

Vorrei andare con OAuth e JWT e programmare personalmente gli extra personalizzati di revoca. Assicurandomi di convalidare normalmente il JWT e di verificare la revoca.

Mi aspetto che il requisito per gli utenti registrati e la revoca venga eliminato e questo mi consentirebbe semplicemente di rimuoverlo.

In Fact, spostiamo gli utenti che hanno effettuato il login direttamente su un componente di reporting anziché su auth, tuttavia possiamo ottenere statistiche migliori in questo modo

    
risposta data 01.08.2018 - 13:16
fonte
0

Non è davvero una risposta, ma è troppo lungo per un commento.

Sei assolutamente sicuro che il tuo client nativo non supporti i cookie? L'articolo menziona che la maggior parte delle buone librerie client li supporta.

Per quanto riguarda JWT: sposali alla tua idea. Ottieni l'ID casuale extra come campo nel JWT. Oppure mantieni una lista di revoche basata sulla firma dei token (che dovrebbe essere unica dopo tutto)

    
risposta data 31.07.2018 - 09:55
fonte

Leggi altre domande sui tag

Test automatico "tutte le modifiche sono contrassegnate da funzionalità", possibile? Dove memorizzare i contenuti statici