Fornire gli identificatori API al lato client

0

Contesto

Sto creando un back-end in questo momento che ha identificazioni univoche (auto-create) per ciascun utente e deve anche memorizzare determinati "token" o altri identificatori per un paio di API di terze parti diverse. Ogni utente ha anche il nome utente e la password di accesso.

Domanda

Non riesco a decidere tra due vie di azione. Il back-end è per i client mobili, iOS e Android, non è sicuro se questo è importante.

Opzione 1:

On the username and password login, return all the tokens so that for future API calls the server can just use the credentials already given in the call from the client. This would reduce queries to the database to get the credentials associated with the UID. I've heard of security concerns about storing information on the client. This security issue on the client seems to be the only con to this approach.

Opzione 2:

Otherwise, the client just sends the uid for the respective account and the backend just makes queries to get the relevant API identifiers for the different APIs. Only con is having to make a lot of calls to get API identifiers every time.

On a similar note is it okay to send the API identifiers and unique IDs of other users to a particular user? It seems like there's not even much more security involved with the second approach because there is just an extra layer of work that provides no extra security in that if someone has access to user information like uid they can (for all intent and purposes) use the corresponding API identifiers indirectly. Any suggestions on which one to use?

Mi sto appoggiando all'opzione 1.

Ho cercato di trovare duplicati, non ne ho trovati. Scusa se l'ho perso.

    
posta esimran 16.03.2018 - 07:35
fonte

0 risposte

Leggi altre domande sui tag