Il client deve avere accesso a token di accesso API di terze parti?

Question

Il client deve avere accesso a token di accesso API di terze parti?

#1 da (1 voti)

1

Sto provando a determinare se utilizzare direttamente un token fornito da un servizio di terze parti, OPPURE emettere il mio token personalizzato e memorizzare il lato del server token di terze parti.

Flusso di autenticazione

L'utente autentica la propria identità tramite una terza parte (accesso basato su social media / gestione identità). Per fare questo inseriscono il loro nome utente e password nella pagina di accesso della Terza Parte (esposta come visualizzazione Web nell'app Client), e la Terza Parte restituisce all'App Client un 'Token di Autorizzazione'.
Il client invia il "token di autorizzazione" al mio server, che in combinazione con una "chiave dell'applicazione segreta" (fornita dalla terza parte) consente al server di scambiare il token di autorizzazione dell'utente per un "token di accesso" (il token in realtà ho bisogno di effettuare chiamate API per conto dell'utente). Ciò che accade sul lato server mi consente di mantenere la mia 'Secret Application Key' segreta e fuori dalla portata del Cliente.
A questo punto non sono sicuro se sia per ...
1. Invia il token di accesso di terze parti al client in modo che possa essere incluso in tutte le future chiamate al server che chiamerà quindi l'API della terza parte, OPPURE
2. Invia un token JWT personalizzato al client, memorizzando il token di accesso della terza parte sul server per ciascun utente.

Intendo effettuare tutte le future chiamate sul lato server API di terze parti, tuttavia i miei dubbi su ciascuna opzione sono:

Se il client ha il proprio token di accesso per il servizio di terze parti, anche se consente solo l'accesso ai dati per i quali l'account ha accesso, significa che potrebbero effettuare ulteriori chiamate API contro i limiti di chiamata della mia applicazione.
Se il server trattiene questo token di accesso di terze parti (non lo invia mai al client), crea una risorsa che è sensibile e deve essere archiviata e protetta. Penserei che sarebbe più sicuro avere solo temporaneamente accesso al token di accesso quando necessario.

Qual è il modo preferito di gestirlo?

authentication session-management

posta Z-Mehn 30.08.2018 - 12:40

fonte

1 risposta

Leggi altre domande sui tag authentication session-management

Gli schemi di autenticazione REST che espongono la chiave condivisa sono protetti contro i proxy inversi che agiscono come agenti utente errati? Azione modulo non specificato - Inquinamento parametro HTTP

score 1 · Accepted Answer

il framework oAuth 2 non regola questo aspetto, quindi tecnicamente entrambi gli approcci vanno bene. Tuttavia, ciò che viene solitamente seguito è quello in cui il server gestisce il token di accesso, insieme al token di aggiornamento (in caso di accesso offline, ad esempio nel framework oAuth di google).

Quando si utilizza un'autenticazione di terze parti, la si utilizza come IDP (provider di identità) in modo che sia possibile allegare l'identità all'utente. Oltre a ciò, come limitato dagli ambiti del token di accesso, è possibile accedere ad alcuni servizi aggiuntivi forniti dal server di risorse di terze parti. Dopo ciò, qualsiasi interazione tra il client e il server dovrebbe essere gestita dalla sessione della propria applicazione. Non dovresti usare il token di accesso come token di sessione nella tua applicazione.

Per commentare lo svantaggio con questo approccio, come hai osservato:

If the server holds on to this Third Party Access Token (never sending it to the Client), it creates a resource that is sensitive and must be stored and protected. I would think it would be safer to only temporarily have access to the Access Token when needed.

Anche se il token di accesso viene restituito al client, è comunque necessario assicurarsi che sia memorizzato nel client in modo sicuro. Ed è più facile fornire tale sicurezza sul server che sul client.

Send the Third Party 'Access Token' to the Client so that it can be included in all future calls to the Server which will then call the Third Party's API,

Questa sembra non essere una buona idea per l'altro motivo che è completamente ridondante in questo caso per instradare la richiesta attraverso il tuo server. Se il client ha il token di accesso (che di solito è un token al portatore), può comunicare direttamente con il server di risorse di terze parti. A meno che il server di terze parti non limiti l'accesso in base alla whitelist IP o ad altri mezzi. Anche in questo caso è meglio avere una sessione personalizzata tra client e server e lasciare che il server parli al server delle risorse usando il token di accesso che salva con se stesso.