Welcome to the final post of the Power of PushAuth™ blog series. In this post, we will enhance the basic website we created in the Building a Web Application with PushAuth™ post by integrating trusted registration to provide a way for the mobile SDK to only register authorized users.
For a detailed explanation on trusted registration, please refer to the following:
In this tutorial, we will integrate trusted registration into a web application so that a user, upon signup, is given a 4-digit “pairing code” they can enter in the mobile app. After this, the mobile client added will be the only one who is able to receive login request push notifications.
To follow this tutorial, you will need:
This tutorial assumes a basic familiarity with the Rails framework. Also, the starting point of this guide is the Rails app we built in the Building a Web Application with PushAuth™ post. If you have not followed this previous post to build the web application from scratch, you can clone the pushauth-sample-server in our GitHub repository as the starting point. If you choose to use the GitHub project as a starting point, make sure to initialize the project by following the steps in the README of the project.
First, we need to add new data to the User table in the database to keep track of an integer pairing code and a boolean that tracks whether or not the code has been used.
Let’s generate a migration to add these columns:
The newly generated migration should look like this:
We also want to add a column to keep track of whether each pairing code has been used. This column should default to false so that we don’t have to set it when we create a user. Add this line under the other add_column line from the migration file:
Run bundle exec rails db:migrate, and we should have the appropriate database setup.
Let’s add some business logic to our User model so that we can ensure the consistency of our table.
We want to add validation to the username such that it must be unique, and we want to add a before_create hook that generates a random verification code for a new User. While we’re at it, we may as well make a function that tries to use up a validation code and returns whether or not it was a success.
A quick note about consume_verification_code: in the absence of any statements following the if, Ruby will return a boolean corresponding to the evaluated condition, so this will return true if and only if the code was correct and had not been used before.
Now, let’s make a UsersController so that we can implement user registration:
In UsersController, we will add three actions:
Now, let’s add some new views.
app/views/users/new.html.erb for the signup page:
And finally, we add our routes:
We now want to add signup links from a couple of different pages:
Replace the Welcome! Please <%= link_to "log in", "login" %>. line in app/views/application/home.html.erb with the following:
And add this to the bottom of app/views/sessions/new.html.erb:
At this point, you should be able to test the new signup flow by running bundle exec rails server.
When the user enters their name and pairing code in the app, the UnifyID PushAuth™ service will send a POST request to the Rails app for permission to add a device. On the Developer Dashboard, you can set up the endpoint URL. A detailed explanation of how the trusted registration webhook endpoint works can be found in the previous blog post.
We will make an endpoint for user verification at /users/trust, which checks if a given user and a challenge token (i.e., the pairing code for this sample website) match with our database records.
Let’s take a look at these in a bit more detail:
By default, Rails has cross-site request forgery protection for forms, which means that a form that submits data via POST will have an authenticity token that makes it difficult for attackers to manipulate your browser into performing unauthorized requests. You can read more about this before_action here.
For our use case, however, the UnifyID service will not know the proper authenticity token, so we relax that requirement on the trust action.
This adds HTTP Basic Authentication to the /user/trust endpoint in order to make sure the request is from the UnifyID PushAuth™ service. Note that you will have to add basic_username and basic_password entries to the Rails application credentials (bundle exec rails credentials:edit).
Finally, we can add our route:
And there you have it! We’ve added user signup, and we have secured mobile client registration to UnifyID PushAuth™ service. The end result should look like our pushauth-sample-server-reg project in GitHub, which was introduced in the Power of Trusted Registration blog post.
This concludes the Power of PushAuth™ blog series. Thanks for following along, and feel free to reach out to us if you have any questions, comments, or suggestions!
To learn more about Prove’s identity solutions and how to accelerate revenue while mitigating fraud, schedule a demo today.
Join over 1,000 businesses that rely on Prove across multiple industries, including banking, FinTech, healthcare, insurance, and e-commerce. Contact us today.
Tap the button below to read our latest white-paper on the subject as industry leaders.
Contact us to learn how leading companies are using Prove Pre-Fill to modernize the account creation process by shaving off clicks and keystrokes that kill conversion.
Get in touch to find out how we can help you identify your customers at every stage of their journey and offer them seamless and secure experiences.
Let our expert team guide you through our identity verification and authentication solutions. Select a date and time that works for you.
Find out how we can help you deliver seamless and secure customer experiences that comply with PSD2/SCA. Select a date and time that works for you.
Download Aite-Novarica Group’s full report about Prove Pre-Fill, including a product overview, customer results, and how the product works.
Download the guide now to learn how you can improve security, cut down on fraud, and create the best possible customer experience.