FR: Validate phone number in the server

[brunolemos]

I'd like to suggest a way to validade the phone number in the server. Something like validatePhoneNumber(verificationId, verificationCode) (which returns the phone number, for example) would be very useful.

Maybe also a validatePhoneNumber(verificationId, verificationCode, phoneNumber) that returns a Boolean.

I don't see how to verify if the phone is valid without creating an account. The client has sent the sms, the user has submited the verification code, but the only methods available are to link or signin (which would create an account with sJks92mda0 uid).

PS: A way to set/change the uid of a firebase user would also be a workaround to me, because then I would be able to create the account in the client and change the uid in the server.

• Operating System version: macOS Sierra 10.12.6
• Firebase-admin version: 5.0.1
• Firebase Product: auth

[brunolemos]

What I'm currently doing, which feels like an ugly workaround:

• Client sends verificationId and verificationCode to the server
• Server create a temporary user account outside firebase (postgres database) to get the incremental id
• createCustomToken(idFromPostgres) creates the firebase user with correct uid
• Link firebase account with the phone using linkWithCredential (had to install firebase package in the server, before it was only firebase-admin)
• If link was successful, great, means phone is valid.
  • If not, deletes the temporary accounts created (on postgres database and on firebase).
• Account successfully created with correct uid.

[bojeil-google]

I am having a hard time understanding your use case. We are working on adding the ability update/create accounts with phone numbers with admin privileges: https://github.com/firebase/firebase-admin-node/pull/58 Typically a user signs in with phone number on the client. After sign-in, you can send the Firebase ID token to your server, and there would be a phone number in that token which you can trust (validated and verified by Firebase Auth).

[brunolemos]

@bojeil-google the use case is that if it's created in the client, the user uid will be something like uJSh399dakms, but the project I'm on was unfortunately implemented in a way that the uid must be the same as the postgres database, e.g. 12345.

So separating phone validation from account creation would be awesome.

[hiranya911]

@brunolemos This sounds similar to #46 (Except with phone numbers, instead of email). Are you requesting for the ability to initiate the phone number verification flow in the Admin SDK?

[bojeil-google]

This is a very specific custom use case. To summarize, you want the ability to do phone authentication but retain the ability to provide your own user ID for the created user. I will suggest one solution:

1. Do the phone auth verification process on the client. At the end of the flow, you have a phone number, verification ID and verification code.
2. Send those to your server if this is a new user (existing user case does not require this).
3. Mint a custom token for your user with your postgres uid (using admin SDK).
4. Use client SDK (node.js one) and signInWithCustomToken.
5. Use customUser.linkWithCredential(firebase.auth.PhoneAuthProvider.credential(verificationId, verificationCode))
6. If this succeeds, your new user has now a verified phone number and has the custom uid you want.
7. You can now send the custom token to the client to signInWithCustomToken and get back that same user on the client.

[brunolemos]

@bojeil-google Thanks, that's exactly what I'm doing at the moment. Initially I found it "wrong" to have to put the client sdk in the server, but it's working fine. Also makes me wonder if signing in/out users in the server frequently won't cause some conflicts, because the app is used by some hundreds concurrently.

[brunolemos]

@hiranya911 it's a bit similar, yes.

Are you requesting for the ability to initiate the phone number verification flow in the Admin SDK?

Yes, kinda, more specifically a way to check if the phone number is valid without creating an account, not necessarily a way to send the verification code sms.

[bojeil-google]

Yeah I see that issue. You would need to use the user reference returned via signInWithCustomToken promise and ignore currentUser or listening to onAuthStateChanged. The performance may not be optimized but you should be OK. I will relay your request to the Auth team. As @hiranya911 mentioned, we've had some other requests for client side API on the admin SDK side of things. Some are prioritized higher than other, like sending email verification.

[brunolemos]

@bojeil-google Thanks! I hope they understand and agree to work on it.

[adirzoari]

@brunolemos I'm looking to do similar thing. did you succeed to do that?

[brunolemos]

@adirzoari I'm doing the way I mentioned above https://github.com/firebase/firebase-admin-node/issues/59#issuecomment-316647790 which is not ideal but works

[adirzoari]

But think about this situation. User sign in with phone for first time, you get his uid then into Authentication table in firebase console it add his phone number and uid. Then user remove app and install again then try to sign in with same phone number,firebase generate new uid. But not update this uid in Authentication table

[adirzoari]

I open my issue here, you can see https://github.com/invertase/react-native-firebase/issues/1064

[replygirl]

Sending & validating verification codes in Cloud Functions is a really obvious capability, it's frustrating it's sitting on the shelf

[martin-braun]

I wonder if this ever will be tackled in my lifetime.

[jbromberg]

Also looking for the ability to send and validate phone numbers & verification codes via the admin sdk and not just the client sdk.

[martin-braun]

I'm sick of Google's ignorance. We need a proper alternative to Google. Some carriers offer email to SMS, but mine does not. Almost all carriers also offer email to SMS, but it requires to know the target carrier, which is not ideal for phone verification.

What's necessary to have full control is just doing it on your own by using an USB to SIM adapter that has a built in GSM modem module. Once connected to a Linux system, it should allow to send the right AT commands to the SIM card to send off an SMS for you. I think this is the real deal, because it allows you to prevent any third company to harvest the phone numbers of your customers, you will have less fees and it would also require to invoke the whole thing server-sided, making it more secure than Google's implementation.

Basically a device like this:

OSTENT GSM Modem Wavecom Q2303A

Appears as /dev/ttyUSB0 in Debian, then allows to send AT commands right to the device. Unfortunately sending an SMS via AT command is pretty annoying, I found some instructions for German carriers, but it's not safe to assume they will work everywhere, I'm not sure.

But having at least two SMS servers, one failover, that actually send real SMS without any third party could be such a benefit that I seriously consider it.