Sto creando un servizio API che richiederà l'autenticazione. questa sarà la prima parte di un progetto che includerà un servizio front-end per il mio sito Web e aprirà anche l'API per i client front-end di terze parti al servizio.
Ho pianificato come sto andando a suddividere il mio sito nel backend / frontend e penso di aver trovato una soluzione in cui non devo avere tabelle utente duplicate, ma volevo vedere se c'erano buchi spalancati nella mia logica ponendo una domanda qui.
Il sistema auth è progettato per essere simile al sistema di autenticazione di Amazon AWS S3 - Assegnare a ciascun utente una chiave e un segreto, quindi utilizzare il segreto per firmare le richieste API dai client front-end. L'API quindi cerca l'utente da api_key, verifica che sia stato firmato con api_secret dell'utente e passi da lì.
Il più grande ostacolo è che voglio che il mio modello utente viva in prima fila. Ciò è dovuto ai legami esistenti tra l'utente, i modelli di abbonamento e le informazioni di pagamento che in realtà non hanno posto nel servizio API. Per funzionare con questo, quando l'API deve cercare un utente api_secret, deve comunicarlo alla mia app front-end (tramite una linea https sicura e un thread diverso) per ottenerlo. Questa immagine ti aiuterà a spiegarlo al punto 4.
Penso che questo fornirà un sistema di autenticazione sicuro per l'API e un modo per qualsiasi client front-end o client di terze parti per implementare i passaggi 1 e 2, pur non duplicando alcun dato utente nel back-end. Il passaggio 4 chiamerebbe comunque sempre la mia specifica app front-end che contiene tutte le tabelle utente.
È un modo stupido per fare questo?