Google voice manual config oauth 2.0

[GPz1100]

It appears obitalk is needed to generate the refresh token to allow google voice to function on the newer firmwares.

Lately I've been playing with various asterisk/pbx implementations.  There's several ways to configure gv trunks depending which implementation is used.

1) plaintext password (same password used to log into google account) (current version of freepbx)
2) refresh token - involves a rather cryptic process to generate the oauth 2.0 token (incredible pbx and some others).

#2 is what I think obitalk does in the background when permission is granted to the obi device via obitalk.

#1 presents a rather serious security flaw with the gv credentials being saved in plaintext.  However, freepbx seems to be most user friendly to a pbx beginner.

It occurred to me, that with 2 step verification, google has something called application passwords.  These are 16 character passwords generated for applications (hardware/software) which does not support the 2 step verification method.  Configuring freepbx with the application password was successful.

Could the same be done on the obi device, eliminating provisioning through obitalk?

Thoughts?

[SteveInWA]

What is the point of doing that?

The benefit of using OBiTALK to provision Google Voice, is that it handles the OAUTH token generation and exchange, and that token only grants access to the XMPP (Chat) service on the Google account.  At no time is a password stored by Obihai, nor on the device.  This is a more secure solution.

[GPz1100]

Main benefit I see is the manual provisioning.  Keeps the obi device from having contact with the mothership.

[SteveInWA]

Well, that's unwarranted concern.  There are hundreds of thousands of OBi products using the portal, and there has never (in many years) been any sort of security breach of an OBi as a result.  Regardless; no, you can't generate your own OAUTH keys yourself and then store them on the OBi.  And, using an app password (which won't work on an OBi) is weak security, as it permits access to the entire Google account. 

An app password is no different than using a standard Google password in that regard, and no different from using a Google password from a security standpoint.

[GPz1100]

Thanks for your perspective.

I was unsuccessful logging into gmail with the app password.  So it would seem web access is limited. That's not to say that access via api's isn't as that's what the whole purpose of the app passwords is (in my understanding).

Still, it would be nice to be able to do the full provisioning manually. That is, obitalk still allows generation of the token but there is no interaction between obitalk and the obidevice.