Download the SecSign ID Node.js API (SecSignIDApi.nodejs.js) and add it to your Node.js project

// include SecSign ID Api for node.js
var SecSignIDApi = require('./SecSignIDApi.nodejs.js');

Request a new session (authentication session) from the ID server. In order to request a session, the user name, respectively the SecSign ID as well as the name of the website, web service or Node.js project have to be sent to the server. The name of the website, respectively web service will be shown to the user on the smart phone.

An authentication session consists of a session ID, the SecSign ID as well as a so-called ‘Access Pass‘. The class for the session is called ‘AuthSession’. The Access Pass includes a Base64 encoded PNG image. This image must be shown to the user. The same image will be shown to the user on his smart phone.

By the comparison of the images the session will be accepted on the smart phone.

// this auth session object will encapsulate all required data such as request id, authentication session id and the secsign id
var authSession = null;
// example for whom an auth session could be requested.
// the value for secsignid should be your SecSign ID which you have created before.
var authenticationSessionFor = {
    "secsignid" : "zoidberg", // the secsign id itself
    "servicename" : "Node.js test", // a name which will be shown in the push notification
    "serviceaddress" : "localhost" // an address which is shown at top in the app, when user has to pick the correct access pass
};
// start by requesting an authentication session
secSignIDApi.requestAuthSession(authenticationSessionFor, receivedAuthSessionCallback);

After a session (authentication session) has been requested from the server the access pass must be shown to the user, e.g on the website. The Access Pass consists of a Base64-coded PNG image. The user compares this image with the images shown on his smart phone. By selecting the correct symbol the user confirms the session.

For websites this session information must be stored in order to later request the state of the session. On websites this can be done via form fields. The example shows the required information for requesting the state of the session later on.

1. Request ID: The Request ID is the ID of the currently requested session. Through this ID all further requests, e.g. a request for the state of the session are assigned
2. SecSign ID: The user name
3. AuthSession ID: The ID of the requested session
4. Service Name: The name of the Node.js project, respectively of the web site
5. Service Address: The IP address, respectively the URL of the Node.js project, respectively of the web site

// call back function for the call of secSignIDApi.requestAuthSession(...)
var receivedAuthSessionCallback = function(authSessionObj){
	if(authSessionObj.error){
		console.log("Error " + authSessionObj.errorcode + " : " + authSessionObj.errormsg);
	} else {
		// received an authentication session
		// sent data is an url encoded parameter list: authsessionid=-429097454724893700&servicename=Node.js test&secsignid=samplesecsignid&authsessionstate=1&serviceaddress=localhost&requestid=.....
		// when data was parsed, it looks like:
		// {
		//	secsignid: 'zoidberg',
		//	requestid: 'F2C5F138E72008AD0ABCC2E83ACCD7B71B415FF58DA35DEAA5AA79D83B939246',
		//	authsessionid: '-8337412603900330717',
  		//	authsessionstate: '1',
  		//      servicename: 'Node.js test',
  		//	serviceaddress: 'localhost',
  		//	authsessionicondata: 'iVBORw0KGgoA ... MAAAAABJRU5Er',
  		// }
  		// again, this is just an example so you know that you will get a hashmap/object or an associative array.
                //
  		// the authentication session icon data must be shown to user e.g. by sending it back to the caller or the website.
  		// to check the authentication state the request id and the authentication session is needed.
  		// therefor the auth session object must be stored by sending it to the browser, so it could be posted back, by storing it in a session object or somewhere else
  		//
		secSignIDApi.log("received auth session: ", authSessionObj);
// create an authentication object. this stores the data about secsign id, request id and auth session id
authSession = new SecSignIDApi.AuthSession(authSessionObj);
// secSignIDApi.getAuthSessionState(authSession);
// secSignIDApi.getAuthSessionState(authSessionObj);
secSignIDApi.getAuthSessionState({
    "secsignid" : authSessionObj.secsignid,
    "requestid" : authSessionObj.requestid,
    "authsessionid" : authSessionObj.authsessionid
}, receivedAuthSessionStateCallback);
}
};

The session which is requested from the server can have different states. As soon as the session is requested from the server, the session has the state „Pending“. When a user wants to confirm the session on the smart phone, the session receives the state „Fetched“. When the user accepts the session by selecting the correct symbol, the state changes to „Authenticated“.

Other possible states are ‘Denied’, ‘Cancelled’, ‘Expired’ and ‘Suspended’. More detailed information can be found in the comments of the class ‘AuthSession‘.
It is necessary to react to the user´s acceptance (‘Authenticated’) or denial (‘Denied‘) of the session.

This can either be done by an action of the user so that, for example, the form (see point 3) can be sent to the server via buttons or via polling. It can be reacted to the state of the server upon receipt. The session can either be accepted, denied or remain pending. The state can be compared with constants of the class ‘AuthSession‘.
In case of a failure during the request of the state an exception will be thrown that can, respectively should be caught.

// call back function for the call of secSignIDApi.getAuthSessionState(...)
//
var receivedAuthSessionStateCallback = function(authSessionObj){
    if(authSessionObj.error){
        console.log("Error " + authSessionObj.errorcode + " : " + authSessionObj.errormsg);
    } else {
        // the received parsed data:
        // {
        //	authsessionid: '-6928134574892437226',
        //	secsignid: 'local',
        //	authsessionstate: '1'
        // }
        secSignIDApi.log("auth session state: ", authSessionObj);
        // check which state the session has
        // PENDING, EXPIRED, AUTHENTICATED, DENIED, SUSPENDED, CANCELED, FETCHED, INVALID, NOSTATE
        if(authSessionObj.authsessionstate == SecSignIDApi.AuthSession.PENDING){
            console.log("the authentication session is pending");
        }
        if(authSessionObj.authsessionstate == SecSignIDApi.AuthSession.AUTHENTICATED){
            //release authSession and log user in
            secSignIDApi.releaseAuthSession(authSession, userIsLoggedInCallback);
        }
        if(authSessionObj.authsessionstate == SecSignIDApi.AuthSession.Denied){
            console.log("the authentication session was denied");
            // cancel session
            secSignIDApi.cancelAuthSession(authSession, canceledAuthSessionCallback);
        }
        // store the new state in auth session object
        authSession.setState(authSessionObj.authsessionstate);
    }
};

If the session is supposed to be cancelled via the client, this can be done via ‘cancelAuthSession‘.

// call back function for the call of secSignIDApi.cancelAuthSession(...)
var canceledAuthSessionCallback = function(authSessionObj){
	if(authSessionObj.error){
		console.log("Error " + authSessionObj.errorcode + " : " + authSessionObj.errormsg);
	} else {
		// the received parsed data:
		// {
		//	authsessionid: '-6928134574892437226',
	  	//	authsessionstate: '6'
	  	// }
		secSignIDApi.log("canceled auth session: ", authSessionObj);
	}
};

The communication with the ID server runs via ‘SecSignIDApi.nodejs.js’. SecSignIDApi objects do not have to be particularly initiated (see the example under 2).

The method for requesting a session requires as parameter the SecSign ID, the name of the web site or project as well as an IP address, respectively the URL of the web site. An AuthSession object will be received, all other functions of the SecSign ID Api require as parameter a valid AuthSession object.

The functions are:

1. requestAuthSession
2. getAuthSessionState
3. releaseAuthSession
4. cancelAuthSession

We provide an ever growing list of APIs and plugins to easily integrate the SecSign ID Two-Factor Authentication in any project. An overview is available at Plugin and APIs.
We do not only offer APIs in different programming languages but also plugins for CMS, Server and VPN environments, oAuth2 and many more. These plugins use our APIs and offer additional functionalities, for example user management, easy and native installation, logging or integration in firewalls or Active Directory.

The JIRA plugin for example uses the JAVA-API. The PHP-Api and JS-API is used by WordPress, Joomla, Drupal, Typo3 and many more. The ASP.net/C#-API is used for the Windows and Cisco VPN and the C-API is used for protecting Unix SSH services. The Objective-C API is used by our AppleTV and iPhone/iPad apps.

You can experience the SecSign ID two-factor authentication and the two-factor login by simply integrating the plugin into your website or test environment. Or you can try out the login process on our website without having to register first. You already have a SecSign ID or you want one? Login now and use the portal or use our hassle free registration.

See for yourself how fast and convenient the login process using challenge-response authentication with 2048-bit key pairs is. There is no need for passwords, and no passwords or other confidential information are ever transmitted. It is easy to integrate and simple to use.

For more information about the patented SafeKey procedure and it's unique security can be found here.

If you are missing an API for the programming language you are working with, feel free to contact us and we’ll find a solution with you. If you need help with the integration into an existing system or you can’t find the plugin for your content management system you are working with, don’t hesitate to contact our support team.