Che flusso di OpenID Connect è giusto per me?

2

Ecco l'accordo. Ho un'applicazione web .NET MVC5 che sto passando allo standard OpenID Connect.

Mi piacerebbe anche poter accedere ai metodi del controller da un'app mobile (molto simile a un'API) per inviare e ricevere dati JSON.

Se ho capito bene, il Flusso implicito ha clienti che recuperano un id_token dal provider OpenID a scopo di autenticazione. Nel caso di un'app mobile, se richiaro un id_token per un client_id che corrisponde al client_id della mia applicazione web, dovrei essere in grado di usarlo per autenticare l'app con il mio back-end web, giusto?

E un Flusso del codice di autorizzazione mi fornisce un token di accesso che mi consente di recuperare i token di aggiornamento in modo da mantenere l'autorizzazione per periodi di tempo più lunghi. Questa autorizzazione quindi si applica automaticamente al mio back-end web, o devo anche eseguire il ping del mio sito web in modo che mi assegni un codice di autorizzazione che recupera da, diciamo, Google?

Infine, c'è un flusso ibrido che combina i due, fornendo un id_token per l'autenticazione, un token di accesso che può essere utilizzato immediatamente per accedere alle risorse delle mie applicazioni web e un codice offline_access che consente al web applicazione per ottenere token di aggiornamento per conto dell'utente anche quando non utilizzano l'applicazione.

Sto pensando a tutto questo? Il mio metodo di autenticazione con la mia applicazione Web dal mio client Android nativo non è affatto un problema di OpenID Connect? Cosa useresti in questa situazione?

    
posta ReimTime 21.04.2015 - 17:08
fonte

1 risposta

0

Come risulta, è una sorta di combinazione del flusso di autorizzazione e del flusso implicito. Il flusso implicito è per le applicazioni client e il flusso di autorizzazione consente l'accesso da server a server, credo.

Quale è stata la risposta giusta è il recupero di access_code da Google, con uno specifico pubblico specificato. Il pubblico è il client_id della mia applicazione web. Il access_code viene quindi fornito all'applicazione Web per autenticare il mio client (sia esso browser o app mobile). L'applicazione web scambia il access_code per un id_token e un refresh_token utilizzando l'endpoint token di Google. Quindi questi token vengono verificati e utilizzati per autenticare le richieste successive.

Da lì l'identità dell'utente viene autenticata, e tocca a me decidere come gestirla, sia che si tratti dell'autenticazione basata su token per l'app mobile nativa o dell'autenticazione cookie per il browser.

    
risposta data 28.04.2015 - 20:43
fonte

Leggi altre domande sui tag