OAuth per autenticazione / autorizzazione multiparty

Naviga le tue risposte
3

Lavoro per una società web in fase di grande riscrittura per separare i dati nella propria applicazione di servizio RESTful: l'obiettivo è poter vendere l'accesso a terze parti e prototipare rapidamente le applicazioni interne senza dover accedere direttamente a il DB.

Al momento abbiamo tre applicazioni: la già citata API dati, un CMS e un front-end. Gli utenti devono essere in grado di accedere al CMS per modificare i dati tramite l'API e ci piacerebbe davvero integrare le nostre app Web di Google in questo, effettuando l'accesso tramite Google. Idealmente, questo userebbe il flusso OAuth, perché è il più trasparente per i nostri utenti - ma non conosco alcun modo per condividere le informazioni OAuth tra le applicazioni senza compromettere la loro sicurezza.

Quello che ho provato

In concreto? Niente. La mia proposta iniziale era quella di generare essenzialmente "Nested OAuth" - impostare la mia applicazione dati come provider OAuth per tutte le altre applicazioni, quindi utilizzare il flusso Google OAuth come standard di autenticazione non specificato all'interno del livello dati - è un'API interamente riposante, quindi sarebbe praticamente trasparente per l'utente, ma sembra violare il concetto di OAuth e sento che dovrebbe esserci un modo migliore per farlo. Il flusso sarebbe simile a questo:

  1. Richiesta di accesso utente per il CMS
  2. CMS ottiene un token di autenticazione dal livello dati
  3. CMS reindirizza l'utente alla pagina di accesso ospitata sul livello dati
  4. Livello dati Ottieni un token di autenticazione da Google
  5. Il livello dati reindirizza l'utente alla pagina di accesso di Google
  6. Google autentica l'utente, quindi reindirizza l'utente al livello dati con un token di autenticazione
  7. Il livello dati utilizza il token di autenticazione per ottenere il token di accesso per i servizi di Google
  8. Il livello dati reindirizza l'utente al CMS con un altro token di autenticazione
  9. Auth Layer utilizza il token di autenticazione per ottenere un token di accesso per i servizi di dati

Ma sembra, beh, goffo. Mi piacerebbe anche non dover forzare l'utente attraverso le pagine "Consenti" mutiple, una da Google per consentire il Data Layer e una da The Data Layer per consentire l'accesso al CMS (o qualche applicazione successiva). Quello di cui ho davvero bisogno è di usare Google per una situazione SSO o Kerberos e chiedere a Google di fornire i biglietti per le mie applicazioni. Se qualcuno conosce un modo per sfruttarlo con Google, sarei lieto di distruggere l'intero progetto.

    
posta FrankieTheKneeMan 08.11.2013 - 21:41
fonte

2 risposte

1

Dopo molte ricerche, ho scoperto che Google ha un verificatore di token di accesso non protetto - link che può essere usato per verificare

  1. Quale applicazione è stata rilasciata al token
  2. Quale indirizzo email il token è stato emesso per conto di

Tenendo traccia del Google Identifier dell'applicazione, il livello dati può accettare un token di accesso e verificarlo per autenticare l'utente e l'applicazione, con un piccolo aiuto da uno schema di firma API standard che coinvolge un segreto noto solo al livello dati e l'applicazione di accesso. Ciò non richiede fiducia, poiché ogni applicazione che richiede informazioni dal livello dati può registrarsi con Google oAuth e, senza il segreto condiviso tra loro, l'API dati non può utilizzare il token di accesso per conto dell'utente. Ciò impedisce al Data Layer di accedere alle API di Google per conto dell'utente, ma è possibile implementare una specifica oAuth specifica per l'API dei dati per ottenere l'accesso alle risorse dell'utente.

    
risposta data 12.11.2013 - 18:43
fonte
0

Penso che la soluzione che proponi sia la migliore che troverai.

Consente di ricapitolare il problema per verificare di averlo capito correttamente. Hai un "Data Layer" che memorizza i dati di proprietà degli utenti. Gli utenti sono autenticati usando l'endpoint OAuth di Google. Hai anche un numero di app "front-end" che possono accedere al livello dati, ma che non sono implicitamente attendibili. Il comportamento che desideri è che se l'utente A approva l'app "Front-end A", l'app può accedere ai dati appartenenti all'utente A nel livello dati, ma non ai dati appartenenti ad altri utenti.

Per supportare questo progetto, ogni utente dovrà approvare esplicitamente ogni app front-end che usa, anche se dovrà farlo una sola volta. Questo è inerente al design. La domanda è se gli utenti eseguano l'autenticazione alle app front-end utilizzando Google direttamente o utilizzando un provider OAuth nel livello dati.

Se utilizzavano direttamente Google, l'app front-end conosceva l'identità dell'utente. Tuttavia, l'app front-end non sarebbe in grado di dimostrare in modo sicuro al livello dati di conoscere l'identità dell'utente. OAuth non supporta questo, e c'è una buona ragione. In questa configurazione, a che punto l'utente accetta di consentire all'app "Front-end A" di accedere al livello dati? Non è possibile per il livello dati aggiungere funzionalità all'endpoint OAuth di Google.

Con l'impostazione "OAuth nidificato" che suggerisci, l'utente vede questo messaggio. E quando lo approveranno, l'app front-end può dimostrare in modo sicuro al livello dati che l'utente ha approvato l'app.

Tra il front-end e il livello dati, stai utilizzando OAuth come originariamente previsto, concedendo alle applicazioni esterne alcuni privilegi sui tuoi dati su un sito web. Tra il livello dati e Google stai usando OAuth per l'autenticazione, che è un caso d'uso leggermente diverso.

Per inciso, si parla di Kerberos, ma questo ha esattamente lo stesso problema. In un ambiente Kerberos, puoi identificarti al server di posta e al file server, ma il server di posta non può quindi autenticarsi sul file server per tuo conto.

    
risposta data 11.11.2013 - 18:42
fonte

Leggi altre domande sui tag

Come intercettare l'url per disabilitare la Navigazione forzata in un semplice progetto Web dinamico? È possibile rilevare e registrare richieste CORS e preflight in IIS?