So I was working with a customer who needed, among other things a friendly and secure telephone directory. The customer would publish a pocket sized paper pamphlet every year. Paper? Really? There must be a better way.

  • Nobody wants to download an app (from Google Play or iTunes). No way, no how.
  • Users really don’t want another login / password for yet another system.
  • Who wants to update a phone directory every time someone joins or exits the group. Not I, said your software developer.
  • We want a system that is easy to update, easy to maintain.
  • If we are talking about members telephone numbers and contact information, secure, protected access is a critical requirement.
  • Just about everyone has access to a mobile phone. Let’s take advantage of that.
  • Utilize tools in the mobile phone browser that make it easy and quick to do phone calls and text paging, via href=”tel:+1…” and href=”sms:+1…”

I had done a project using Google Apps Script and Google sheets as a data storage medium. There were some issues there.. the script ran in the browser which required an publicly shared Google sheet. Cool idea, if the use case fit that situation. Great for product listings, not great for personal data.

I saw a note somewhere about the new offerings from Google including offerings for Firebase mobile phone authentication, including a healthy free tier. Free tier, wow, I’m all in. As an introduction, Google Firebase is a suite of support tools, that was initially used in support of Android Apps. Google has expanded the offerings to include iOS, Android, and the Web. Setup includes content written for Swift, Objective-C, Java, JavaScript, C++ and Unity !
The available tools include Cloud data storage, data synch services, messaging delivery services, analytics, marketing tools and the thing I’m interested in, Authentication. The pricing for the phone authentication service free tier is pretty awesome: 10,000 / requests free per month.

The tool I’m interested in using is Authentication via phone. A website displays a mobile phone number submit. Google Firebase authenticates the phone number via a mobile sms text page with a confirmation code. As designed this is a pretty awesome way to confirm a true mobile phone number… think of marketing folks who want to harvest new users by their telephone number. (I have a couple of customers very interested in doing this type of harvesting…) And in my case, i’m taking this one step further. I’m adding specific user authentication code via “Custom Claims” by editing the Firebase user data store. The authentication code is buried in the token, provided to the web browser client via Google JavaScript bit of code. Upon receipt of the token, the website creates a AJAX request back to server. The server tests the token, and provides appropriate response depending on the users authority. Here is the reference information on using auth tokens (with custom claims) to restrict access. Note: There is a bit of a restriction placed on the free access tier from Google here. It takes a two way trip from the server to add custom claims to a users content at the Google Auth storage. The free tier limits that to 30 requests per hour. Its fine for a managing small team of users, but no way would that work for a large user base. You’d have to increase to a paid service. I will say, that’s more than fair…

Here is a sketch of the authentication process and data flow:

The whole thing works via JSON Web Tokens. JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA.

Do note, this isn’t a perfect high security system. Tokens are stored in browser cache. Anybody who shares phones is sharing the browser content. Its a lightweight security system, but probably appropriate for current usage, a phone directory or secure reference content for a small business’ employees.

Software Tools Used Here:

  • jQuery Mobile. A nice mini framework for this type of application
  • Google Firebase
  • Simple Node Express server. Framework generated via Express application generator
  • Docker used in a Virtual Private Server (proveout via docker on localhost)
  • Ajax call to server on the phone list. The server verifies token and the custom claim, then returns content
  • JSON Web Tokens
  • Google Sheets API v4
  • Mobile browser links for phone calls and text paging, via href=”tel:+1…” and href=”sms:+1…”

User Data Store:

Content is stored in a private shared Google sheet. We use Google Apps Script, and the Sheet API v4 to gain server access to the user data. Again, we’re obtaining this info from the node.js server, not from the browser. What really makes this nice is non-technical folks can easily keep the data updated via Google Drive. The data can be easily updated from a mobile phone to add new users.

Possible Enhancements:

Although I haven’t analysed all the how-to details, it should be possible to send out notifications to all users in the system via SMS messages. I can see where this could be very helpful. Another possible enhancement, more oriented to reference data, is using Progressive Web Apps to control the storage of protected data in cache. I have one customer possible application for this technology, where users are sometimes not located in an area with mobile phone reception.

Conclusion:

The tools available from Google are pretty awesome. Firebase can be used to supplement a whole lot of applications. In this case we are using the mobile phone authentication tools to authenticate and restrict data access to a small group of users. Google Apps Script, the support tools for Google Drive applications (including Google Sheets, online spreadsheets) is way helpful for prototyping applications, or applications where non-technical folks can keep private data easily updated.