C'è qualche svantaggio nell'usare la "pseudoautenticazione" di OAuth rispetto a OpenID?

OAuth è stato progettato per i casi in cui l'Applicazione X deve accedere alle risorse (ad esempio "le mie foto" o "il mio indirizzo email" o "il mio calendario") controllate dall'applicazione Y e appartenenti all'Utente A - L'utente A potrebbe voler concedere accesso a tali risorse sull'applicazione Y, ma non vuole fornire a X l'effettivo nome utente / password. Quindi un token di accesso viene utilizzato come credenziale alternativa per una risorsa sull'applicazione Y. I token di accesso possono essere revocati indipendentemente dalle credenziali di nome utente / password e sono, idealmente, strettamente ristretti per consentire solo l'accesso a risorse specifiche.

Uso di OAuth 2 per sovraccarichi di autenticazione che si modellano in modi che possono essere rischiosi. Guarda l'esempio sopra, e immagina che venga usato per l'autenticazione. Se l'Applicazione X utilizza quel token di accesso per l'autenticazione, prende un token che concede l'accesso alle risorse sull'Applicazione Y e lo utilizza per concedere l'accesso alle proprie risorse. Forse si tratta di spaccare i capelli, perché la cosa importante è che sappiamo che l'atto di concedere un token di accesso tramite OAuth 2 implica che l'utente si è autenticato con successo. Il problema è che il token di accesso non dice nulla su quale applicazione l'utente finale ha autenticato per . Quindi cosa succede se l'Applicazione Z ha anche un token di accesso per le risorse dell'utente A sull'Applicazione Y? Se l'applicazione Z può ottenere l'applicazione X per utilizzare questo token di accesso, allora ha accesso alle risorse dell'utente sull'applicazione X . Questo è male. L'utente A può avere l'applicazione Z attendibile per accedere alle sue risorse sull'applicazione Y, ma l'utente A non ha certamente mai acconsentito all'applicazione Z per accedere alle sue risorse sull'applicazione X.

OpenID e OpenID Connect sono specificamente progettati per l'autenticazione. OpenID Connect è basato su OAuth 2 in modo che possa sfruttare le interazioni e i flussi esistenti, ma aggiunge un'entità chiamata token ID, che è un oggetto contenente un insieme di attestazioni su un evento di autenticazione. Tali affermazioni includono un identificatore per l'utente che ha eseguito l'autenticazione, un identificatore per il server che ha gestito l'autenticazione e un identificatore del pubblico dell'autenticazione. Ciò fornisce a un'applicazione le informazioni necessarie per convalidare che un utente è autenticato per suo conto.

Ogni volta che confronto i due li considero come la differenza tra un modello di identificazione / autenticazione attivo e passivo con openID che è passivo, OAuth attivo.

Passive indica all'applicazione richiedente cosa fare, come ad esempio un browser Web che reindirizza dal provider di identità all'applicazione e il browser è un client stupido di base perché fa solo ciò che gli è stato detto di fare. Active richiede che l'applicazione richiedente sappia cosa fare quando trasmette i dati e fa tutto ciò che desidera con i dati, ad es. il token.

I modelli attivi consentono all'applicazione di effettuare una richiesta diretta a un'API con il token dell'utente perché ha il token memorizzato localmente. I modelli passivi richiedono all'utente di autenticarsi con un reindirizzamento al provider e di tornare all'applicazione con un token temporaneo. (non tecnicamente temporaneo, ma si adatta alla spiegazione)

A seconda di cosa stai cercando di fare con la tua applicazione, entrambi i modelli potrebbero funzionare.

• OAuth è un protocollo di autorizzazione, piuttosto che un protocollo di autenticazione. L'uso di OAuth come metodo di autenticazione può essere definito come pseudo-autenticazione.
• OpenID è specificamente progettato come protocollo di autenticazione.

La differenza cruciale è che nel caso di utilizzo dell'autenticazione OpenID , la risposta del provider di identità è un'asserzione dell'identità; mentre nel caso di utilizzo dell'autorizzazione OAuth , il provider di identità è anche un provider API e la risposta dal provider di identità è un token di accesso che può garantire all'applicazione l'accesso continuo ad alcune API del provider di identità, per conto dell'utente. Il token di accesso agisce come una sorta di "chiave di valet" che l'applicazione può includere con le sue richieste al provider di identità, il che dimostra che dispone dell'autorizzazione dell'utente per accedere a tali API.

Poiché il provider di identità tipicamente (ma non sempre) autentica l'utente come parte del processo di concessione di un token di accesso OAuth, si è tentati di visualizzare una richiesta di token di accesso OAuth come metodo di autenticazione stesso. Tuttavia, poiché OAuth non è stato progettato pensando a questo caso d'uso, l'assunzione di questa ipotesi può portare a grossi problemi di sicurezza

Origine