How inWebo works

Trusted Devices, OTPs, and connectors

Trusted devices are authentication methods that can be used for your inWebo-enabled applications. Trusted devices include web clients (browsers, web views) and native clients (mobile Apps, desktop clients) on a user equipment such as a computer, a smartphone, a tablet.

inWebo one-time passwords (OTPs) are a proof of a user’s identity when signing in to your applications and remote access. Except for codes sent in short-text messages, inWebo OTPs are generated locally by a user’s trusted device and verified by inWebo platform. inWebo supports 3 authentication scenarios:

  • Two-factor: OTPs use two distinct information, called factors, a trusted device (“what I have”) plus the choice of a PIN (“what I know”) or a biometric print (“what I am”).
  • Step-up (aka ‘two-step verification’): inWebo is used after a primary authentication managed by your organization, usually asking the user for her username and password. OTPs use one factor only, a trusted device.
  • Device-stamping: this scenario is used by organizations to restrict from which browsers users can access the applications. OTPs use one factor only, a trusted device.

To generate an OTP for a transaction, a trusted device uses mathematical cryptographic functions called hash functions. Simply put, hash functions transform the authentication factor(s) into a device-dependent, transaction-specific, unique password. That password proves the user identity without revealing anything about the authentication factors. For those interested, inWebo has designed and patented authentication algorithms where the trusted device factor is not static but randomly dynamic. This ensures a much higher security than software certificates or software implementations of authentication standards such as TOTP, HOTP, or FIDO.

MFA set-up application-side

To enable inWebo on an application for the two-factor, step-up, or device-stamping scenario, you need to configure inWebo as the authentication service for that application and to declare that application in your inWebo tenant (you need to sign up for an organization account first, e.g. by starting a free trial).

There are various methods available that can be used to ‘connect’ your applications to your inWebo tenant, such as inWebo SAML IDP, inWebo radius interface, inWebo API, and vendor-specific plugins. See inWebo developer website for more info.

User provisioning and trusted device activation

Before a user can be authenticated using inWebo, her profile needs to be provisioned into your inWebo tenant using IWDS (inWebo Directory Synchronization tool) or inWebo API. The user also needs to register at least one trusted device. In particular, since inWebo browser-based authentication method works without a plugin, registering a web browser as a trusted device is a totally frictionless experience.

inWebo has streamlined the device registration process to simplify MFA roll-out. When a username or alias is provisioned into your tenant, inWebo platform issues a Secure Site ID (= activation code) that will be used to activate and register new trusted device(s). This code can either be distributed to the user by inWebo or returned to you if you prefer to distribute yourself with your own procedures. The benefit of having inWebo handle the distribution is that we provide the user with a link to a customizable enrollment workflow for her trusted device(s), such as her current browser or App. If your organization handles the activation code distribution, you need to build your own enrollment workflow using inWebo API.

Upon registration of a trusted device, secret keys are generated in the background and securely exchanged between the trusted device and your tenant on inWebo platform. These keys are securely stored both in the trusted device and in inWebo platform. Think of some kind of certificate, but much more secure and without the headache for admins and users. The keys – the trusted device factor – are unique to the user, the trusted device, and your application.