Two-way Strong ¦ Sign In ¦ New User

Application Programming Interface (API)

 

Introduction

User Account

API Key

Test Environment

Web Application

Login

Token

Session Check

Session Check (Static)

Logout

Logout (Static)

Mobile Application

Mobile Login Check

Key Data Fields

Response Messages

Demo Examples

Powered By (Credit)

Technical Support

 

Web Application User Access

Figure 1 shows a high-level diagram on user access in a Web application when user authentication returns successful. The user login page allows a registered user to send a one-time passcode to their mobile phone or e-mail account. The one-time passcode serves as a token that is issued to the registered user. The token page allows the registered user to complete the login procedure by submitting their user name and one-time passcode. A failure will redirect the registered user to an error page or a lock page, and the registered user is notified by SMS text message or e-mail message. If the registered user's account successfully passes authentication protocols, the registered user is authorized access and is connected to the secured Web page. Two-way Strong records that the registered user has logged in successfully. Two-way Strong also records login failures. The secured Web page can have a logout button for the registered user to log out of the Web application. When the logout function is used, Two-way Strong records that the registered user has logged out of the Web application. The registered user must then use the login page to log in again.

Figure 1: Logical Progression of User Access in a Web Application
Note: The simplified process flowchart assumes that a registered user has passed authentication protocols.

The software developer can incorporate the user login and token pages into their Web application and apply their own style to make those two pages match the look and feel of their Web application. The user login and token pages can be implemented as static HTML pages. Both the user login page and the token page must be implemented, because these two pages perform a logical sequence in user authentication. The initial user login page does not actually log the registered user into the Web application. It is carrying out a preliminary verification check on the registered user's account. The token page does the actual user login.

The secured Web page is any existing page that the software developer has and wants to protect from unauthorized access. The software developer will add additional computer program code in that page. The additional code executes a function to re-verify the registered user's account and session at the time of access. If verification passes, the registered user is allowed to access the content of the secured Web page. If verification fails, the registered user will be redirected to an error page. If verification results in an expired session, the registered user will be redirected to the user login page.

Static HTML pages can be secured by using the Two-way Strong API. While most implementations are for Web applications that use a Web server script such as ASP.NET or PHP, the Two-way Strong API can be implemented in a simple Web site such as a personal site. Individuals with little to no computer programming skill can provide a level of protection to their Web site. A family, for example, can limit access to very personal stories to friends and relatives.

The logout function is an option that is available to the software developer. As a part of a main menu or some other navigation scheme in the secured Web page, the logout function is implemented as a button or a link. Clicking on the button or link will connect to Two-way Strong to log the registered user out of the Web application. The software developer will add additional computer program code to implement the logout function.

The software developer may decide not to implement the logout function. In this case, user access is dependent on the length of time that the session remains active for the registered user. By default, a session stays active for six hours. The software developer can override the default time period by setting a shorter or longer duration. The session time period will be reset when the registered user successfully accesses the secured Web page a subsequent time within the period that the session is active. The reset will extend the session time period for another full period from the time of access.