OIDC non supporta la concessione di credenziali password proprietario risorse. Perché? Alcuni dei miei client sono dispositivi protetti che potrebbero conservare le credenziali in modo sicuro ... Tali credenziali potrebbero essere utilizzate per ottenere un access_token. Posso ancora utilizzare OpenID Connect?OpenID Connect: credenziali password proprietario risorsa
Non è esplicito nelle specifiche ma OpenID Connect supporta tutti i flussi OAuth 2.0 poiché è un'estensione di OAuth 2.0.
I colloqui spec sui flussi che coinvolgono redirect del browser in quanto sono più comuni, più sicuro e meno fragile dato che credenziali del proprietario delle risorse supporta solo username e password ed è solo nelle specifiche OAuth 2 per la compatibilità all'indietro. Nei veri sistemi SSO si vorrebbe astrarre dal metodo di autenticazione dell'utente all'OP/IDP. Coinvolgere un browser è un modo per farlo.
Ma il tuo chilometraggio può variare. supporto in specifici software OP/AS e librerie client.
FWIW: si dovrebbe cercare un ID_token anziché un token di accesso.
OpenID Connect esegue l'autenticazione per accedere al finale o per determinare che l'utente finale è già connesso. OpenID Connect restituisce il risultato della autenticazione eseguiti dal server per il cliente in un modo sicuro in modo che il Cliente possa fare affidamento su di esso.
Con i codici impliciti ed autorizzazione concedere tipi flussi, non è possibile emettere un token ID, se l'utente finale non è connesso. In questo caso, il server di autorizzazione può confermare al relying party che End- L'utente ha effettuato il login. Con il flusso di tipo di concessione del proprietario della risorsa, il server di autorizzazione non può confermare l'accesso dell'utente finale. È possibile emettere un token di accesso anche se l'utente finale non ha effettuato l'accesso.
Questa risposta confonde le cose: l'autenticazione dell'utente viene sempre eseguita dal server di autorizzazione, anche/anche in il flusso di credenziali password proprietario risorse (ROPC). La differenza sta nel fatto che in ROPC il client "vede" il nome utente/password del proprietario di risorse a differenza degli altri flussi, il che sconfigge lo scopo principale di un protocollo SSO federato come OpenID Connect in cui i meccanismi e le credenziali di autenticazione dovrebbero essere indipendenti dal client/app. Per questo motivo non vedrai molto l'utilizzo di ROPC in OpenID Connect, con un'eccezione forse nei casi di utilizzo intra-aziendale. –
-1 L'offerta non spiega in alcun modo perché il flusso ROPC non possa essere utilizzato in OIDC. Come @HansZ.detto, il server di autorizzazione esegue ancora l'autenticazione in un flusso ROPC. – djule5
Grazie per i vostri commenti. Ho aggiornato la mia risposta in quanto non era chiara. –
Sì . Ho anche trovato la risposta per la stessa domanda a volte indietro. In base alle specifiche OpenId Connect, si consiglia di utilizzare i tipi di sovvenzione authorization code e implicit per le richieste OpenId Connect. Ma non è detto che altri tipi di sovvenzioni non possono essere usati. Pertanto è possibile utilizzare qualsiasi altro tipo di concessione per la richiesta di autenticazione di OpenId Connect. C'è una mail dal gruppo openid connect, che è stato discusso al riguardo. Si prega di trovarlo da here. Se il tuo server di autorizzazione OAuth2 lo supporta, suppongo che sia corretto utilizzarlo. Come so, la maggior parte dei server di autorizzazione lo supportano, ad esempio da here
Grazie! "Nei veri sistemi SSO si vorrebbe astrarre dal metodo di autenticazione dell'utente all'OP/IDP". Potresti per favore approfondire su questo? Mi piacerebbe usare SSO anche per i miei dispositivi sicuri ... Mi manca il punto? – Dunken
ciò che in genere non si desidera è estendere il client con tutti i possibili meccanismi di autenticazione che il provider di identità può utilizzare; immagina ad esempio l'introduzione dell'autenticazione del secondo fattore: il tuo cliente dovrebbe preoccuparsi di implementarlo, basta lasciarlo al browser –