Sto cercando di capire come aggiungere login e registrazione social a un servizio. Dopo aver letto molti post sui blog, molti mi hanno ricordato le insidie della progettazione di un tale sistema, del fatto che Oauth è per l'autorizzazione e non dell'autenticazione, la maggior parte scritta da persone che esplorano questo argomento mentre scrivono, tutti con opinioni diverse su cosa OpenID / OpenID connettono / etc è tutto, mi sto trovando più confuso di prima che iniziassi.
La mia comprensione è che con il Social Login il provider ID fa l'autenticazione. Quando l'utente è autenticato, il client (o l'agente utente) deve essere in possesso di qualcosa (un token sicuro?) Che indica che l'utente è riuscito a dimostrare la propria identità. Sulle successive richieste a / the / API, il server, che dal punto di vista del provider ID è di terze parti (chiamato relying party in alcuni documenti?) Dovrebbe essere in grado di verificare questo "token" e deve essere in grado di derivare da questo "token" che è l'utente reale.
Quindi, in termini pratici:
- Che cosa riceverebbe l'API dal client quando un utente ha eseguito l'accesso utilizzando con accesso social?
- Che cosa riceverà l'API dal client quando un utente si registra con accesso social?
- Come minimo è necessario archiviare su ciascun utente a scopo di autenticazione (ID utente? Email per il ripristino / collegamento di più account? ID-provider (in quale formato?), Elenco delle sessioni correnti / date di scadenza? Ultimo tempo di accesso / aggiornamento forse? Che altro?)
Il sistema corrente (un'API completa REST) emette un token quando l'utente accede con email / password con un post a api.example.com/session . In questo caso l'API è in grado di verificare che l'utente abbia fornito le credenziali corrette.
Ho appreso che molti articoli online parlano solo di come utilizzare i token per consumare le risorse fornite da quella stessa organizzazione, ad esempio l'accesso a Facebook per il consumo delle API di Facebook. Questo potrebbe essere solo il mio malinteso però.
Alcune domande specifiche:
- Che aspetto ha questo token? Rivela l'Identity Provider o come verificare la validità del token?
- Il token fornisce al relying party (i server di backend API) un modo per ottenere, ad esempio, il nome completo o l'indirizzo e-mail dell'utente? O sarebbe la funzionalità delegata al Cliente?
- Chi determina quali informazioni fornisce questo token: il provider ID o l'applicazione client?
- Che dire del caso di un client Web in cui il client e lo user-agent non sono in esecuzione sullo stesso dispositivo? Il client o l'agente utente può "creare" un nuovo token che può essere utilizzato per firmare le richieste all'API e includere i dettagli importanti (ID utente, provider di ID, data di scadenza, ID cliente)?
- L'endpoint "sessione" dell'API può essere esteso per gestire i token di "accesso social" o non è l'approccio corretto?
- È importante identificare / autenticare il cliente? In tal caso, credo che i client mobili non possano archiviare in modo sicuro una chiave di firma!?
Una nota su oAuth e autorizzazione: non penso di aver bisogno di autorizzazione qui. L'API determina già se le richieste sono autorizzate in base all'utente identificato.