OAuth/OpenID basato sul browser con accesso permanente

Question

Abbiamo una normale applicazione Web con autenticazione basata su cookie e ora vogliamo dividere frontend e backend (api) per avere API pubbliche di terze parti. Quindi il nostro back-end sarà su un dominio e il frontend su un altro.

Per l'autorizzazione, desideriamo passare a OAuth 2 with JWT. In questo caso il nostro frontend applicazione dovrà utilizzare access_token invece di cookie di sessione e porta un grande vecchio domanda:

come rimanere connessi in - The Infamous "Remember Me" Casella (parte II da Form based authentication for websites)

Dal punto di vista di OAuth2 la nostra applicazione di frontend userà qualcosa tra Resource Owner Password Credentials Grant e Implicit Grant. È più vicino a Credenziali password Concedere poiché utilizzeremo ancora il modulo di accesso abituale e non reindirizzeremo l'utente a un altro dominio per accedere. Allo stesso tempo è più vicino a Concessione implicita poiché tutto sta per essere solo per il browser & JavaScript basato quando access_token verrà salvato nel browser.

La RFC says il server di autorizzazione non deve emettere un token di aggiornamento se si utilizza implicito di Grant e la mia domanda è se è ancora valido in questo caso l'uso quando non si ha realmente utilizza un 3-d partito OAuth ma la vostra propria API? Istintivamente ritengo che avere refresh_token nel browser sia un buco di sicurezza e vorrei confermarlo con voi ragazzi, ma che lo refresh_token sembra essere l'unico modo per avere un accesso persistente che funziona allo stesso modo dei cookie.

---

UPD dopo il commento @FlorentMorselli:

spec L'OpenID ancora non rispondono alla mia domanda, se posso usare refresh_token con il browser unica applicazione

• Google says forniscono refresh_token solo per access_type=offline
• OpenID Connect Core says non è possibile utilizzare il token di aggiornamento con il flusso implicito
• OpenI D Collegare Nucleo says nulla sull'utilizzo refresh_token con Hybrid flusso
• C'è solo one place in cui si dice qualcosa di promettente circa refresh_token con flusso ibrida, ma niente di preciso

---

UPD2 grazie alla @reallifelolcat

Sembra che OpenID Connect non supporti esplicitamente Resource Owner Password Credentials Grant, ovvero che tu debba reindirizzare l'utente al server OpenID Connect per eseguire il login. Sai se esiste un altro modo per autenticarsi con le credenziali dell'utente su OAuth 2.0?

---

credo api scissione e frontend sta diventando sempre più comune in questi giorni e sarei grato se si condivide come risolvere questo problema persistente Accesso e se si elimina completamente e user forza per ri-login ogni X settimane.

Grazie!

Answer 1

I token di accesso e i token di aggiornamento non hanno nulla a che fare con login con OpenID Connect. Questi sono solo per autorizzare l'accesso alle informazioni del profilo utente e per le chiamate di servizio forse autenticate alla tua API pubblica dopo il login. Fare riferimento alle specifiche per la differenza tra il token ID e il token di accesso.

Se utilizzi OpenID Connect per l'accesso, quindi da quello che hai scritto finora, sembra che tu debba ospitare il tuo OpenID Provider (OP) poiché vuoi evitare di andare in un altro dominio per firmare in:.

abbiamo ancora intenzione di utilizzare al solito modulo di login e non favore utente a un altro dominio, al fine di accedere

Se si vuole essere il proprio provider di identità, quindi più potere a te. Ciò significa che dovrai implementare la tua istanza di lavoro di un server OpenID Connect, completo di endpoint di autorizzazione e token.

Ora questa è la parte in cui entra il tuo accesso persistente. La tua webapp del browser sarà una parte relying al server OP che hai ora. Quando un utente tenta di accedere all'app del browser utilizzando OpenID Connect, sarà necessario autenticarsi sul server OP. Passando attraverso il flusso OIDC, l'app browser riceverà un token ID contenente una coppia emittente/soggetto che identifica l'utente.

E 'a voi per determinare in che modo l'utente rimane effettuato il login al server di OP, ma fino a quando l'utente almeno autorizza l'applicazione del browser una volta: http://openid.net/specs/openid-connect-core-1_0.html#Consent allora si può risparmiare che il consenso per tutte le richieste future di questo browser app per accedere e quindi mantenere un accesso persistente.

Dovrai considerare come gestirai la gestione delle sessioni, ma sembra che tu stia già facendo un po 'di cookie, quindi potresti essere in grado di usarlo (vedi questa risposta: OpenID sign in mechanism - Stay signed in). Altrimenti, finirai con una situazione in cui la tua webapp del browser deve ottenere sempre un nuovo token ID.

Inoltre, come menzionato da Florent, ci sono considerazioni sulla sicurezza da tenere in considerazione quando si fa una cosa pubblica per client che sarebbe la tua applicazione web basata su browser. Esempio: https://tools.ietf.org/html/rfc6749#section-10.16