An application that uses username and password for its login mechanism, generally trusts a store (database, 3rd party service, etc) to verify the fact that the user-password combination exists and fetches the associated information.

Keeping the store and its data safe is a challenge that many companies struggle to achieve.

With iWelcome Authenticator, you do not have to store any kind of password, except the identity of a user (e-mail, username, etc) and trust iWelcome Authenticator to authenticate the user for you (either via push notifications or secondary mechanisms). Using this system, passwords will be completely removed from the equation.

The iWelcome authentication process can be handled in two ways: by using our JavaScript login widget or performing server-to-server API calls.

Using our JavaScript login widget

On your login page, include the login widget. Once a user is authenticated, they will be redirected to the login widget's URL of your application, along with a token inside the query string.

On the server-side, fetch the token from the query string and perform an API call to /v1/token to request the user information.

Since iWelcome Authenticator validates and authenticates all the user information, if the token call is a success, you can then start the user's session, essentially log him in. In a user-password application, this would be the equivalent of querying the database for the username and password.

// Pseudo-code
on GET /uauth/login // or the equivalent login web hook
   authToken = request.query.token
   if authToken does not exist
      redirect back to /login // or equivalent
   else
      tokenData = call api.authenticator.iwelcome.com/v1/token with { token: authToken } including X-Api-Key and X-Api-Secret headers
      generate session using tokenData.user // object containing information about the user.
      redirect user to home page // dashboard or equivalent
   endif

Performing server-to-server API calls

In this scenario, you have full control over the UI and UX of your login or on-boarding forms. In your application's route (or controller) that handles login functionality (POST /login or equivalent) instead of doing a query on your database, you perform an API call to /v1/authenticate send in the request's payload, the user's e-mail address.

iWelcome Authenticator will validate the credentials and ask for the user's approval. When the user accepts the login request, a token will be generated and returned to your server.

You will then use that token to perform a call to /v1/token, in order to retrieve the user's information (similar to the situation above) and start the session.

// Pseudo-code
on POST /login
   result = call api.authenticator.iwelcome.com/v1/authenticate with { email: body.email } including X-Api-Key and X-Api-Secret headers
   if result.type == success then
      tokenData = call api.authenticator.iwelcome.com/v1/token with { token: result.token } including X-Api-Key and X-Api-Secret headers
      generate session using tokenData.user // object containing information about the user.
      redirect user to home page // dashboard or equivalent
   else
      if result.error.code == "APPROVAL.DENIED"
         ask the user to supply the One-Time Password (under the "Tokens" app menu)
      else
         render result.message // tell the user why the authentication request fail
      endif
   endif

Both of cases above rely on the iWelcome Authenticator distributed authentication mechanism to verify the identity of users in order for them to gain access to your application, and in both cases, your users are no longer required to use a password!