Some mobile operators can add the phone number or some other user identifier as an HTTP header via a transparent proxy on all requests passing through their network.
This is/was used for micropayments for services and app downloads via phone bill, for example.
It would only work over mobile data, though (i.e. users would need to disable wi-fi for every authentication and it would not work without cell signal at all, unlike SMS-OTP or actual SIM authentication).
Huh... so I guess it's entirely reliant on the mobile operator adding this header then, and it's literally just checking whether the phone number in the header matches?
I think the intended method of using this API is to use apis from within a mobile app to make the request transparently (and ensure mobile data is used to avoid users having to manually disable wifi), but the person in the article is just generating a QR code that you have to scan so I assume you would indeed have to disable wifi by hand each time which would make it more trouble than its worth.
I had no idea mobile network operators were tacking on my phone number to requests though (presumably unsecure http only but still)...
Sorry, that was imprecise – as far as I know it's not actually all HTTP requests, but rather only those on a list of URLs that the operator has a contractual agreement with. (I'd like to believe that this does not include advertisement/tracking purposes, or that the identifier is at least hashed for those...)
Regarding an API to bypass Wi-Fi: I think at least on iOS, such a thing does not exist, and on Android I'd be extremely annoyed as well if an app were to possibly incur data and/or roaming charges for this. (I'm not sure whether there is an Android API to send only a specific request over mobile data without impacting other, already existing connections.)
> Sorry, that was imprecise – as far as I know it's not actually all HTTP requests, but rather only those on a list of URLs that the operator has a contractual agreement with. (I'd like to believe that this does not include advertisement/tracking purposes, or that the identifier is at least hashed for those...)
Ah, that makes more sense.
> Regarding an API to bypass Wi-Fi: I think at least on iOS, such a thing does not exist, and on Android I'd be extremely annoyed as well if an app were to possibly incur data and/or roaming charges for this. (I'm not sure whether there is an Android API to send only a specific request over mobile data without impacting other, already existing connections.)
I believe the Andorid ConnectivityManager API allows this. I didn't realize iOS didn't have something similar, although there are probably good reasons not to want apps to be able to do this.
The phone number is used to create the check url. This check url is returned from the mobile network operator that phone number and SIM card belong to.
The device makes a GET request to the check url, with a cellular data connection. The mobile network operator is able to verify that the phone number used to create the check URL matches that of the phone number assigned to that SIM Card making the data connection request.
And if SIM Swap is a concern, we also have an API that allows you to first check whether that phone number has recently switched SIM cards before proceeding with the verification.
> The device makes a GET request to the check url, with a cellular data connection. The mobile network operator is able to verify that the phone number used to create the check URL matches that of the phone number assigned to that SIM Card making the data connection request.
I was curious how this actually worked but according to Lxgr's reply the network operator adds HTTP headers that allow the phone number to be verified.
This is/was used for micropayments for services and app downloads via phone bill, for example.
It would only work over mobile data, though (i.e. users would need to disable wi-fi for every authentication and it would not work without cell signal at all, unlike SMS-OTP or actual SIM authentication).