There is a web application that allows users to register by email and activate their account by the link in the email. And there is an application on android that communicates with the web application through json.

The goal is to enable users to register and log in to our web application through VC. On android, vk android sdk is used, user_id, token, and any personal information about the user (full name, gender, date of birth, etc.) is obtained during authorization on the client.

The question is - having this data, how can the server know exactly what is valid data? How to protect yourself from requests with random data that is “similar” to valid data? Indeed, in the case of registration by email, our guarantee of validity was a mandatory confirmation of the account by reference in the letter. And when registering for VC such a scheme is no longer. All traffic from the client to the server is open, not encrypted, easily intercepted by any sniffer (ie, you probably shouldn't send a token to the server).

    1 answer 1

    Yes. For authorization you will have to transfer to the server token. Further, the server with this data will need to contact the secure.checkToken method to verify the token sent by the user. The application itself must be registered in the VC.

    If you are worried about the very fact of the transfer of the token, you can:

    1. use SSL / TLS to encrypt the connection. There should be no problem with this.
    2. Token has a lifetime. You can periodically update and reauthorize it (but this option is not very).
    3. Do not think that someone is sitting under your doors and trying to get the exact set of characters out of all traffic (he is not known in advance). At the same time, the one who sits under your doors has no idea what protocol is being exchanged, whether it is going at all, whether you are using the program at this moment, on which port the connection is, at what point the authorization is going on, etc. etc. The fact that you can see the data with a sniffer does not mean at all that someone will be able to see them as well and certainly does not mean that they will be able to use them at the moment (and when you re-authorize, see clause 2). In theory, you can fantasize a lot of things, but in practice it will be easier to drive needles under your fingernails to the user in order to learn access passwords.