The benefits of using a mobile phone, advice an existing device that a user already carries around with them, as a token are well understood. However there are scenarios where two-factor authentication is required but the use of a mobile phone as a token is not possible, which is why the Swivel platform offers token-based authentication for those who need it.

The tokens supported by Swivel are OATH TOTP (time-based) or HOTP (eventbased). To authenticate, the user presses the button on the token and an OTC is displayed to the user. The user enters this OTC on the login page in order to authenticate. The users PIN can be combined with the OTC if required.
For customers requiring banking-level security and transaction authorization, the Swivel platform also supports the OATH Challenge-Response Algorithm (OCRA). In this mode the user enters a specified challenge into an OCRA token (eg destination account number) and then enters the response into the authorization dialogue on the transaction screen.


Tokens can be used with or without PINs. When the platform is configured to use PINs, you simply add your PIN to the end of the 6 digit OTC generated by the token without any decoration (i.e. “,”)

Token administration

Tokens are provisioned onto your Swivel Core Platform by uploading the seeds and serial number data via the admin console which is then stored in an encrypted format. The type of token, ie TOTP or HOTP is specified as the tokens are imported.

If you have this seed information for other OATH tokens, you can migrate these tokens from another OATH server to your Swivel server.
As with other forms of authentication, users are configured to be able to use tokens by being made part of OATH token users groups.
The administrator can then allocate a token to any eligible user via the admin console.

Token synchronisation

The Swivel server can calculate the expected OTC from any given token. This is based on knowing the seed for that token and the token’s event number.
For time-based the event number is calculated based on the current time. For event based the event number is the number of times the button has been pressed.
To cater for clock drift or if, on event based tokens the button is pressed at times other than at authentication, the system administrator can specify two parameters.

Error Window

If the difference between the event number calculated by the server and the actual token event number is less than the error-window, the authentication is allowed.

Sync window

If the difference between the event number calculated by the server and the actual token event number is greater than the error window but less than the Sync window, the authentication will fail but the server eventnumber count on the server is updated. This means if the user attempts to authenticate again, the next authentication will succeed.

Manual sync

To manually synchronise a token you need to enter two successive one-time codes for the token. This can be done either by the administrator via the Swivel admin console or by the user via the user portal.

Platform Specifications
User Interface Up to 8-characters high contrast
LCD display. Built-in button
Security Algorithms OATH compliant event-based
(HOTP), time-based (TOTP),
challenge-response (OCRA)
Memory Type Random Access Memory (RAM)
Endurance More than 14,000 clicks
Battery Lifecycle >4 years
Power Consumption Less than 0.005mW
Operating Temperature (-4°F ~ 158°F)
Humidity 0% ~ 100% without condensation
Security Tamper evident. IP54 ingress