When mobile app connects to back-end and requests the data, back-end should be sure that requestor is one it pretends to be. So, we need some way to securely identify the app on a device.
While loking for best practices on mobile device identification against mobile back-end, I have found a set of solutions, from just identifying by device ID to using relatively short living tokens (oAuth2 tokens, JWT tokens or just session IDs)
But all methods I have found include transfer of some reusable strings (tokens) that are vulnerable to interceprion. Reusable meaning that if someone has the string, he/she can use it to act on device's behalf.
Even over https, when user is in some closed environment (say, corporate network), he/she may be required to install additional certificate and that string may be intercepted and used for unauthorized access to user data ("mitm attack").
I can think of the following methos to avoid this attack, while keeping things still relatively simple:
- Mobile App, on a device, during initial "registration" call generates public/private key pair. Private key is securely kept on a device.
- Public key is sent to back-end, and stored next to device's ID (clarification: it's done once in an identified device lifetime, before any other auth actions that allows act on user's behalf)
- On each request device sends short "random" string (GUID, or current time, or something got from back-end), and this string, encrypted with a private key
- Back-end checks if the "random" string is random enough (not used before) and if encrypted data can be decrypted with public key to that very "random" string. And, if so, confirms device identity.
This seems pretty simple (both iOS and Android has infrastructure for PKI).
And still secure (not vulnerable to mitm attack, impossible to mimic).
The question is - why it is not widely used (or at least widely discussed)?
Is it something standard, that I just do not know how to name correctly?
Is it known to be a bad practice for some reason?