Introduction

This is for Version 3.0 of Simply Sign In

We all know the kind of hassles current credential systems create in our lives. Usernames, passwords, emails, OTPs .... all of them are such a bother. We have a separate section explaining the pain we go thru for each of those systems.

Simply Sign In is a refreshing, extremely simple and quite unique (Patent applied for) method for authenticating users. Usually the authentication is done to gain entry into Websites/SaaS/Video Conferences/Movies/Music and such like.

But we can see it being used for other activities too: For e.g. we can see a merchant developing an application to let their registered user open physical doors at the entrance of protected premises/vehicles/etc.

To use Simply Sign In; a merchant has to take an account with us. He then sets up a shared secret with us and ask his developers to write some simple code as per our specifications. And that's it!

Who is this documentation meant for?

This documentation is mainly meant for those merchants who want to use our system as an authentication system. This can also be read by advanced users of those merchants who are keen to know how our system allowed them to use those merchants' offerings.

Summary of how this works

Lets say some wants to take an account at one of our merchant's website or SaaS app or whatever is that the user wants to use. (Henceforth, in these docs, we'll assume that user wants to enter the merchant's website.)

Such a potential user has to visit a special entry page on that website. It will ask for the user's mobile phone number; and once that is number is given .... that page will display a message asking the user to enter a special SMS (text message)* containing a numeric 6 digit code at the end. That code is called a "TOTP" (time sensitive one-time-password)

The user then sends that SMS message to the end point as explained earlier. In a minute or two, the user would find that he/she is now allowed into that website. It is AS SIMPLE AS THAT!

And lastly... and obviously... we use our own system to let such merchants take an account with us.

Version Changes

From version 3.0 of our system, we have also implemented an alternative to SMS: Instead of an sending the aforesaid message containing the TOTP, via SMS; it is possible to send an email to a special inward email address. This is currently experimental but it is stable. This new version is useful for those merchants who are not comfortable asking their user to send in an SMS. This documentation continues to use the term SMS, phone number etc.... but the working for the email based Simply Sign In algorithm is the same as that for phone based algorithm. Instead of using the SMS to send a message, the user sends the entry message as a SUBJECT line in an email to us. Caveat 1: Please note there is a slightly more chance of hackers masquerading as an authentic user if the email route is used in our system. Why? Because ALL email systems implement a username + password system; and if the user was a bit careless the email may get accessed by others without the knowledge of the user. The hacking will not happen at a mass scale but at an individual level, a few users may find that their merchant accounts were entered into without their permission. Caveat 2: There is one major disadvantage of using the user's email address as the origination point: The same user can take many accounts! Why so? Because it is usually extremely easy to create a new email account and use that for registering. If a merchant who is implementing a product which requires the users to be reasonably authentic, we strongly recommend that you use the users phone-number as the originator and not email address. Caveat 3: Also, though we do a lot of checks to see if the email address sent by the user is not spoofed, email technology is a very old system which is full of holes. There are sometimes ways by which an earnest hacker can convince our system about an email address as being the origination, when the hacker in fact had spoofed it.

In short; use the email way of using Simply Sign In as an authentication system only for those product/services where you don't mind an individual there getting lots of different accounts in your service/product. And you should consider additional verification methods at your server too: E.g. Checking answers to some previously asked questions (that were set at the time of a new registration), etc.

These docs are meant for messages sent by either SMS and/or EMAIL In these docs, we assume that the authentication message has been sent via SMS -- but really speaking; the docs equally applies to the authentication message being sent via the SUBJECT line of an email from the user's email address.