Quali sono le principali differenze tra l'autenticazione JWT e OAuth?

Ho una nuova SPA con un modello di autenticazione senza stato che utilizza JWT. Mi viene spesso chiesto di fare riferimento a OAuth per i flussi di autenticazione come chiedermi di inviare "token bearer" per ogni richiesta anziché una semplice intestazione di token, ma penso che OAuth sia molto più complesso di una semplice autenticazione basata su JWT. Quali sono le principali differenze, dovrei fare in modo che l'autenticazione JWT si comporti come OAuth?

Sto anche usando il JWT come XSRF-TOKEN per impedire XSRF ma mi viene chiesto di tenerli separati? Devo tenerli separati? Qualsiasi aiuto qui sarà apprezzato e potrebbe portare a una serie di linee guida per la comunità.

TL; DR Se hai scenari molto semplici, come una singola applicazione client, una singola API, allora potrebbe non pagare per diventare OAuth 2.0, d'altra parte, molti client diversi (basato su browser, mobile nativo, lato server , ecc.) quindi attenersi alle regole di OAuth 2.0 potrebbe renderlo più gestibile rispetto al tentativo di implementare il proprio sistema.

Come affermato in un'altra risposta, JWT ( Learn JSON Web Tokens ) è solo un formato token, definisce un meccanismo compatto e autonomo per la trasmissione di dati tra le parti in un modo che può essere verificato e attendibile perché è firmato digitalmente. Inoltre, le regole di codifica di un JWT rendono anche questi token molto facili da usare nel contesto di HTTP.

Essendo autonomi (il token effettivo contiene informazioni su un determinato argomento) sono anche una buona scelta per implementare meccanismi di autenticazione senza stato (alias Look mum, no sessioni! ). Quando si percorre questa strada e l'unica cosa che una parte deve presentare per ottenere l'accesso a una risorsa protetta è il token stesso, il token in questione può essere chiamato token al portatore.

In pratica, ciò che stai facendo può già essere classificato come basato su token al portatore. Tuttavia, considera che non stai usando token al portatore come specificato dalle specifiche relative a OAuth 2.0 (vedi RFC 6750 ). Ciò implicherebbe, basandosi sull'intestazione AuthorizationHTTP e utilizzando lo Bearerschema di autenticazione.

Per quanto riguarda l'uso del JWT per prevenire la CSRF senza conoscere i dettagli esatti, è difficile accertare la validità di tale pratica, ma a dire il vero non sembra corretto e / o utile. Il seguente articolo ( Cookie vs token: Guida definitiva ) può essere una lettura utile su questo argomento, in particolare la sezione Protezione XSS e XSRF .

Un ultimo consiglio, anche se non hai bisogno di completare OAuth 2.0, ti consiglio vivamente di passare il tuo token di accesso all'interno Authorizationdell'intestazione invece di utilizzare le intestazioni personalizzate . Se sono veramente token al portatore segui le regole di RFC 6750, in caso contrario, puoi sempre creare uno schema di autenticazione personalizzato e utilizzare comunque quell'intestazione.

Le intestazioni di autorizzazione sono riconosciute e trattate in modo speciale da proxy e server HTTP. Pertanto, l'utilizzo di tali intestazioni per l'invio di token di accesso ai server di risorse riduce la probabilità di perdite o archiviazione involontaria di richieste autenticate in generale, e in particolare delle intestazioni di autorizzazione.

(fonte: RFC 6819, sezione 5.4.1 )

OAuth 2.0 definisce un protocollo, ovvero specifica come vengono trasferiti i token, JWT definisce un formato token.

OAuth 2.0 e "Autenticazione JWT" hanno un aspetto simile quando si tratta della (seconda) fase in cui il client presenta il token al Resource Server: il token viene passato in un'intestazione.

Ma "l'autenticazione JWT" non è uno standard e non specifica in che modo il client ottiene il token in primo luogo (la prima fase). Ecco da dove viene la complessità percepita di OAuth: definisce anche vari modi in cui il Cliente può ottenere un token di accesso da qualcosa che viene chiamato un server di autorizzazione.

Quindi la vera differenza è che JWT è solo un formato token, OAuth 2.0 è un protocollo (quello può usare un JWT come formato token).

Innanzitutto, dobbiamo differenziare JWT e OAuth. Fondamentalmente, JWT è un formato token. OAuth è un protocollo di autorizzazione che può utilizzare JWT come token. OAuth utilizza l'archiviazione lato server e lato client. Se si desidera eseguire il logout reale, è necessario utilizzare OAuth2. L'autenticazione con token JWT non può effettivamente disconnettersi. Perché non hai un server di autenticazione che tiene traccia dei token. Se si desidera fornire un'API a client di terze parti, è necessario utilizzare anche OAuth2. OAuth2 è molto flessibile. L'implementazione di JWT è molto semplice e non richiede molto tempo per essere implementata. Se la tua applicazione richiede questo tipo di flessibilità, dovresti scegliere OAuth2. Ma se non hai bisogno di questo scenario d'uso, l'implementazione di OAuth2 è una perdita di tempo.

Il token XSRF viene sempre inviato al client in ogni intestazione di risposta. Non importa se un token CSRF viene inviato o meno in un token JWT, poiché il token CSRF è protetto con se stesso. Pertanto l'invio di token CSRF in JWT non è necessario.

JWT (token Web JSON) - È solo un formato token. I token JWT sono strutture di dati con codifica JSON che contengono informazioni sull'emittente, l'oggetto (reclami), il tempo di scadenza, ecc. È firmato a prova di manomissione e autenticità e può essere crittografato per proteggere le informazioni del token utilizzando un approccio simmetrico o asimmetrico. JWT è più semplice di SAML 1.1 / 2.0 e supportato da tutti i dispositivi ed è più potente di SWT (Simple Web Token).

OAuth2 : OAuth2 risolve un problema in base al quale l'utente desidera accedere ai dati utilizzando software client come app Web basate su browser, app mobili native o app desktop. OAuth2 è solo per autorizzazione, il software client può essere autorizzato ad accedere alle risorse per conto dell'utente finale utilizzando il token di accesso.

OpenID Connect - OpenID Connect si basa su OAuth2 e aggiunge l'autenticazione. OpenID Connect aggiunge alcuni vincoli a OAuth2 come UserInfo Endpoint, token ID, rilevamento e registrazione dinamica dei provider OpenID Connect e gestione delle sessioni. JWT è il formato obbligatorio per il token.

Protezione CSRF : non è necessario implementare la protezione CSRF se non si memorizza token nel cookie del browser.

Puoi leggere maggiori dettagli qui http://proficientblog.com/microservices-security/

Sembra che tutti quelli che hanno risposto qui abbiano perso il punto controverso di OAUTH

Da Wikipedia

OAuth è uno standard aperto per la delega dell'accesso, comunemente utilizzato come modo per consentire agli utenti di Internet di concedere a siti Web o applicazioni l'accesso alle proprie informazioni su altri siti Web, ma senza fornire loro le password. [1] Questo meccanismo viene utilizzato da aziende come Google, Facebook, Microsoft e Twitter per consentire agli utenti di condividere informazioni sui propri account con applicazioni o siti Web di terze parti.

Il punto chiave qui è access delegation . Perché qualcuno dovrebbe creare OAUTH quando esiste un'autenticazione basata su id / pwd, supportata da un'autorizzazione multifattoriale come OTP e inoltre può essere protetta da JWT che vengono utilizzati per proteggere l'accesso ai percorsi (come gli ambiti in OAUTH) e impostare la scadenza del accesso

Non ha senso usare OAUTH se i consumatori accedono alle loro risorse (i tuoi end point) solo attraverso i loro siti Web (o app) fidati che sono di nuovo ospitati sui tuoi end point

Puoi eseguire l'autenticazione OAUTH solo se sei OAUTH providernei casi in cui i proprietari delle risorse (utenti) desiderano accedere alle loro (tue) risorse (punti finali) tramite un client di terze parti (app esterna). Ed è stato creato esattamente per lo stesso scopo sebbene tu possa abusarne in generale

Un'altra nota importante:
stai usando liberamente la parola authenticationper JWT e OAUTH ma non fornisci il meccanismo di autenticazione. Sì, uno è un meccanismo token e l'altro è protocollo, ma una volta autenticati vengono utilizzati solo per l'autorizzazione (gestione degli accessi). Devi sostenere OAUTH con l'autenticazione di tipo OPENID o le credenziali del tuo client

trova le principali differenze tra JWT e OAuth

1. OAuth 2.0 definisce un protocollo e JWT definisce un formato token.

2. OAuth può utilizzare JWT come formato token o token di accesso che è un token di connessione.

3. OpenID connect utilizza principalmente JWT come formato token.

JWT è uno standard aperto che definisce un modo compatto e autonomo per la trasmissione sicura di informazioni tra le parti. È un protocollo di autenticazione in cui consentiamo il trasferimento di attestazioni codificate (token) tra due parti (client e server) e il token viene emesso al momento dell'identificazione di un client. Ad ogni richiesta successiva inviamo il token.

Considerando che OAuth2 è un framework di autorizzazione, in cui ha una procedura generale e configurazioni definite dal framework. JWT può essere utilizzato come meccanismo all'interno di OAuth2.

Puoi leggere di più su questo qui

OAuth o JWT? Quale usare e perché?

La domanda è comune, ma non è del tutto ragionevole. JWT è un tipo di token e OAuth è un framework che descrive come distribuire token.

Cosa intendiamo per "quadro"? Solo la sequenza di richieste e risposte e i formati di quelle che possono e devono essere utilizzate per richiedere token. OAuthv2 descrive "flussi" separati o tipi di concessione per diversi scenari e ha estensioni diverse (come PKCE) per estendere la sicurezza di flussi particolari.

Il risultato di una richiesta di token tramite una concessione OAuthV2 è ... un token. Quella cosa viene quindi utilizzata come "token al portatore", il che significa che qualsiasi parte che detiene il token può presentarlo quando effettua una richiesta di assistenza API (ad esempio, "qual è il saldo sulla mia carta di valore memorizzata?"). Come token Bearer, funziona come denaro contante. Se lo tieni, puoi usarlo. (Anche se a differenza del denaro contante, un token non lo usa e lo perde. Forse un'analogia migliore è un biglietto tutto il giorno per viaggiare sul sistema di trasporto pubblico o un biglietto per tutto il giorno a Disneyworld.)

JWT è un tipo particolare di token e JWT può essere assolutamente utilizzato come token OAuth Bearer. In realtà, questa è la pratica più comune. Alla luce di ciò, "JWT vs OAuth" è un confronto tra mele e carrelli di mele.

Spesso la gente pensa che il "token OAuth" implichi sempre un token opaco - una sequenza casuale di caratteri alfanumerici che non ha alcun significato intrinseco - che è concesso da un dispensario di token OAuth, che può quindi essere validato solo dallo stesso sistema di dispensario OAuth. Ma questo non è l'unico tipo di token OAuth. Un token opaco è un tipo di token; JWT può essere utilizzato come un diverso tipo di token OAuth.

JWT, al contrario, non sono opachi. JWT non è un "puntatore" o un riferimento alle informazioni. In realtà contiene molte informazioni specifiche, che possono essere estratte e interpretate da qualsiasi parte che ha il token. Poiché il JWT contiene informazioni reali, un JWT può essere di grandi dimensioni; 300 byte, 500 byte o più, a seconda delle affermazioni contenute al suo interno e dell'algoritmo utilizzato per firmarlo. Quando le persone affermano che "JWT si auto-convalida" ciò che intendono è, qualsiasi titolare di JWT può aprirlo, convalidarlo e quindi prendere decisioni di autorizzazione basate sulle affermazioni in esso presentate. Convalidare JWT significa: verificare la sua struttura, decodificare la codifica base64, verificare che la chiave sia corretta, verificare la firma, quindi verificare che le richieste richieste siano presenti nel token, controllando la scadenza. Non è una cosa semplice piuttosto un processo in più passaggi, ma ovviamente ci sono molte librerie in vari linguaggi di programmazione che si adeguano a questo, e ovviamente c'è la politica di VerifyJWT che ti aiuta a farlo all'interno di un proxy API Apigee Edge. Il punto è che qualsiasi titolare o destinatario può verificare un token. Per questo motivo, diciamo che JWT supporta "Federazione": chiunque può generare un token e chiunque può leggere e convalidare un token.

reclami personalizzati. Sia i token JWT che i token OAuth opachi possono portare rivendicazioni personalizzate sull'argomento. sicurezza. Entrambi sono token al portatore. Entrambi devono essere protetti come segreti. scadenza. Entrambi possono essere contrassegnati con una scadenza. Entrambi possono essere aggiornati. Il meccanismo o l'esperienza di autenticazione. Entrambi possono presentare la stessa esperienza utente.

Jwt è un insieme rigoroso di istruzioni per l'emissione e la convalida di token di accesso firmati. I token contengono attestazioni utilizzate da un'app per limitare l'accesso a un utente

OAuth2 d'altra parte non è un protocollo, è un framework di autorizzazione delegato. pensare a linee guida molto dettagliate, per consentire agli utenti e alle applicazioni di autorizzare autorizzazioni specifiche per altre applicazioni sia in ambienti privati ​​che pubblici. OpenID Connect, che si trova in cima a OAUTH2, ti fornisce i dettagli di Autenticazione e Autorizzazione.it su come più ruoli diversi, utenti nel tuo sistema, app lato server come un'API e client come siti Web o app mobili native, possono autenticarsi con ogni altro

Nota oauth2 può funzionare con jwt, implementazione flessibile, estendibile a diverse applicazioni