SecSign ID: Your solution for secure user authentication or complete identity and access management. Use extremely convenient, but at the same time the highest security industry standards for your user authentication in all your services.
What is FIDO and WebAuthn?
FIDO2 is a set of specifications including the World Wide Web Consortium’s (W3C) Web Authentication (WebAuthn) specification and the FIDO Alliance’s corresponding Client-to-Authenticator Protocol (CTAP). FIDO2 enables users to leverage common devices to easily authenticate passwordless to online services both in mobile and desktop environments, and to utilize authenticators including USB/NFC security keys like the YubiKey or smartphones.
In practice the user will register one or more FIDO authenticators on a web service and can then use it to authenticate and confirm a sign-in for example. When visiting the secured web service, the browser will ask the user to connect the FIDO authenticator to the device and press a button to register/login. Or it will utilize the built-in platform authenticator by asking for a fingerprint or using the face recognition capability of the smart phone or computer. The user is then authenticated with the touch of a button.
Manage the FIDO devices yourself including onboarding and deleting (if allowed by the admin)
Manage your users directly in the SecSign ID IDM/IAM or connect your existing user directory like an Active Directory, LDAP, Azure, …
Use groups to control which user uses FIDO
Admins can specify which kind of FIDO tokens are allowed. E.g. disallow platform authenticators or FIDO devices with weak security features to conform to a high standard policy or a required audit
Realise a secure and comfortable two-step login for users where the first step is an username/password login and the second step is FIDO 2FA for example
Use the self-services to see all activated FIDO devices/tokens
Add a fallback 2FA/MFA method to your activated method
You can also disallow specific FIDO authenticators that are outdated or compromised for example or just allow specific devices from a whitelist
Add more than one FIDO device to your account, so you can still sign-in if you lose the FIDO device (if allowed by the admin)
Use many different 2FA methods in the SecSign ID server like Email OTP, SMS OTP, TOTP apps and tokens, the SecSign app for mobile and desktop and of course FIDO
Allow users from the internal company network to sign-in without 2FA by using IP whitelists
You have the choice: Use the server in our cloud or host it yourself on premise
Give your FIDO tokens/devices a nickname when onboarding them
Security Keys and Platform Authenticators
Use hardware tokens with your smartphone (NFC / Lightning / USB)
Use hardware tokens with your computer (USB and NFC)
Use hardware tokens with or without biometrics
Use your device e.g. iPhone, Macbook, Windows Hello PC or Android Phone as FIDO token without additional app or hardware (platform authenticators)
There are two different kinds of FIDO authenticators to authenticate yourself on a website: Hardware tokens a.k.a. security keys and platform authenticators.
Hardware FIDO authenticators like a Yubikey security stick can use connectors like USB, BT or NFC. There are also some hardware token for the iPhone lightning connector. Most hardware tokens have a button to confirm the authentication. Some also support biometrics like your fingerprint. And some even have a display to show you informations about the website.
If you use a hardware authenticator you can use it on any device you need to log into a website. You just plug it in the USB port or hold it against the NFC reader of your computer or smartphone.
Platform authenticators are bound to a specific device and the operating system will manage the authentication. They are build into the operating system of your device and use the integrated TPM of your computer or smartphone. The platform authenticators are available on all current major platforms like iOS, iPadOS, Android, Windows and macOS. You can’t use these to login on a different device. These also often only work in some specific browser. On macOS for example you can only use TouchID as a platform authenticator in the Safari browser or the Chrome browser but not in Firefox. Also if you registered using Safari you can’t use Chrome to login and vice versa.
Hardware authenticators however are supported in all major browsers on all platforms. So they are more flexibel, but you can also combine them and use more than one FIDO authenticator to authenticate a login for a web service. For example you can use the platform authenticator in your iPhone to authenticate just with FaceID, while also having a Yubikey to authenticate when you are on your computer or use it to login on a device which you don’t own.
Passkeys from Apple, Google and Microsoft
With the newest versions of their plaforms Apple, Google and Microsoft now also support the use of multi-device platform authenticators. You can use passkeys on another device by synchronizing the devices in the cloud and use QR codes to utilize them on another platform. This allows an user to use an iPhone to authenticate a web session on Microsoft Windows for example. In this case the iPhone will create a secure channel to the Windows machine to do the login. The technology is called Passkeys and an extentions of the FIDO standard. It works on Apple’s iOS, iPadOS and macOS, on Google’s Android and ChromeOS and on Microsoft Windows.
Hardware authenticators are supported on all current versions of Windows, macOS, Linux, iOS, iPadOS and Android. All major browsers on these platforms support them.
Platform authenticators are also available on all current platforms, but they require a Trusted Platform Module (TPM). Most recent iPhones, iPad and Android smartphones already support this. For macOS you need a recent version to use it with Touch ID and on Windows 10 it works only with supported computers.
Technical Background of FIDO
FIDO is using public key cryptography to secure the authentication just like the SecSign ID. When registering a FIDO authenticator the browser will ask the device to generate a keypair. The public key is sent to the server along with some metadata about the authenticator. This is all digitally signed to so it can’t be tampered with. The server will save the public key and cryptographically verify that the FIDO device owns the corresponding private key by doing a challenge response exchange. This all happens in the background and the user just has to press a button on the device to confirm the registration.
When authenticating the user the procedure is similar. The user starts the login on a website. The server will do a challenge response authentication with the FIDO device to confirm the identity of the user. The user has to confirm this on the authenticator by e.g. pressing a button. The server cryptographically checks the result and logs the user into the web service.
All registered authenticators are bound to the hostname on which they are used. So changing the access URL will invalidate all registered authenticators for the service. In that case the user has to register the authenticator again. That’s also one of the advantages of the FIDO protocol because it’s phishing resistant as the user can’t login to a wrong website. The browser and the FIDO device will check the website domain for the user and will only allow a login if it fits.
Use it with SecSign
You can use your FIDO authenticators with all our SecSign products. For example, our Atlassian Plugins support FIDO devices as an authentication method. You can use it with Confluence, Jira or Crowd as your default or as a backup method for login.
It’s also possible to use it with your on premise server to enable it in your custom applications and services. When using the SecSign ID Server as an Identity Management server you can use FIDO as an authentication method in all your authentication flows. Use it as your primary authentication method or in combination with the SecSign ID mobile app or any other supported authentication method (TOTP, SMS-OTP, Email- OTP, …) in your service. The authentication methods can be set globally or can be configured using user groups. The user groups can be managed by the SecSign ID Server or by your Active Directory.
FIDO can be integrated in your existing SAML or OAuth flows or you can just use the REST-API in your custom backend to support it. The onboarding and authentication can be done by redirecting to the SecSign ID server so your own service doesn’t need to know any details about the authentication or by including it in the custom application to integrate it deeply into your existing flow.
FIDO Device Meta Data in SecSign
In the dashboard of the SecSign ID server the user and the admin can get infos about the registered FIDO authenticators. This includes the vendor and product name and also a self selected nickname to differentiate the authenticators.
The SecSign ID server also checks and validates the metadata of the FIDO authenticators. You can get infos about the used authenticator and can also require specific security levels or only allow some FIDO devices that you trust. The meta data includes infos about the capabilities of the authenticator, if they are certified, known security vulnerabilities and detailed infos about the security properties of the device. All this data can be used to define policies to allow or disallow some FIDO authenticators for example to require some specific security property for authenticators that are used in admin account or to only allow a specific product that is whitelisted by the company.
Example Authentication Flow from User Perspective
The user wants to use your custom web portal. In the integrated flow the user is prompted for the username (an email address in this case). In the redirect flow the web application will redirect the user to the SecSign ID server where he is prompted for his username. In case the user already authenticated the single-sign-on (SSO) will do the login automatically without user interaction. If the user authenticated before the username field can be already filled of course.
The user is now prompted for the password if two-step-authentication (2SA) is activated. This is optional and can also be skipped if the admin configures it in the SecSign ID server.
The SecSign ID server will now check if a two-factor-authentication (2FA) is required and if the user has already onboarded the second factor. You could only require 2FA if the user comes from an unknown browser or IP for example.
The server will also check what authentication method is allowed for the user e.g. FIDO or the SecSign mobile app. If the user is allowed to use more than one authentication method he can choose which one to use. This is done by checking to which user group the user is assigned to in the SecSign ID server or a connected Active Directory.
If he chooses “USB security key” he will be asked by the browser to connect it to the computer and press the button on it. If he chooses “this device” he would have to confirm with biometrics or the pin of the device.
Once he confirmed on the FIDO device the registration or authentication is complete. The SecSign ID server will now redirect the user back to the custom
web service which will log the user in. Or, if using the integrated flow, the web service will log the user in directly.
In this flow the admin of the SecSign ID server can also configure if he wants to only allow hardware FIDO tokens for example or some other security policy like requiring an FIDO certified authenticator with some specific security level.
Scalability of FIDO Rollout with SecSign
To rollout FIDO authentication in your existing infrastructure can seem complex and laboriously. But the SecSign ID server has many features so that many time-consuming tasks are no longer necessary.
The SecSign ID server delivers specific enrollment/onboarding/management web pages for FIDO so you don’t have to take care of the activation, management and usage of the FIDO tokens. This is all included and you won’t have to implement it yourself or do this tasks manually. But we also have a REST API so you can integrate it in your web service if needed.
FIDO is not just Hardware Tokens
If you think of FIDO you maybe thinking of hardware tokens like the Yubikey. But all your smartphones, laptops and desktop computers also have a FIDO client integrated. This is called a platform authenticator. So no extra hardware is required. And you can combine them in what ever way you want. Users can use the integrated FIDO platform authenticator on their work computer and also use an security stick if they are not in the office for example. The SecSign ID server also allows you to control who can use what FIDO device, so you could require an admin user to use a stronger authentication device for example.
Combine FIDO with other authentication methods
You can not just use more than one FIDO device for authentication. You can also combine FIDO with all the other authentication methods the SecSign ID server supports. For example the user could use a FIDO platform authenticator in the office and the SecSign ID mobile app from home. Or you could require multiple authentication methods for some cases, like an additional SMS OTP if the IP address is unknown. All this can be comfortable configured in the SecSign ID server by using user groups.
Self Service for Lost Devices etc.
The SecSign ID server has included self services for all needed management tasks like adding a new device, deleting an old device, handling lost devices, changing authentication methods, etc. All this can be done by the users themself and don’t have to be done manually by the admin.
Three Ways to Integrate FIDO into your Infrastructure
1. Use Standards like SAML, OAuth or OpenID Connect
Connect the SecSign ID server using SAML, OAuth or OpenID Connect to your own services or to cloud services that you use. You can secure the services according to your policies and define for your user when they have to use which authentication method. The SecSign ID server can provide you also with a Single-Sign-On (SSO) in this context. You can use the server only as a MFA/2FA authentication server or as a complete identity management (IDM) solution.
The advantage of using one of these standards is that you don’t have to care about the implementation details of the FIDO authentication (or of the other supported authentication methods). The complete logic of the authentication flow and scenarios like losing the second factor, onboarding, selection of different authentication methods, etc. is all delivered by a website served from the SecSign ID server. And all this websites are customizable to your corporate design.
In this context most customers also connect their existing Active Directory to the SecSign ID server to also run the password authentication over it. We recommend this way especially if your want to secure many service with 2FA or bring together more than one identity source like an Active Directory.
2. Use our REST API
The advantage of this is that you don’t have to bother with a protocol like SAML or OAuth and have a tight integration in your web service without any redirects in the browser.
3. Use our existing Plugins
Use FIDO in your services with our existing plugins. For example we have plugins for all the Atlassian services like Jira, Confluence and Crowd that already support FIDO.
Backup for lost FIDO devices
If your users are using a FIDO device to authenticate to your service, you also need to handle the cases where they lose the device. One way is to always register a second FIDO authenticator. Users can for example use a FIDO security stick like the Yubikey and also register a FIDO platform authenticator as a second device, like their smartphone or laptop. That way they can still login if they lose one of these.
Another way is to use the SecSign ID mobile app as a backup or alternativ authentication method.
There are also other advantages of the SecSign ID mobile app:
- You can use it to login on any device and not just on the same (unlike a FIDO platform authenticator)
- You also don’t need to have USB, Bluetooth or NFC on the device where you want to login (unlike a FIDO security stick)
- The SecSign ID is not limited to web authentication but can also be used for all other authentication scenarios
- The SecSign ID has an easy and secure restoration procedure if the user loses the smartphone without using a second device – just a backup code and an email address.
- And, as you authenticate on your smartphone, the device where you are doing the login can use any operation system or browser (even older ones or the smartphone the SecSign ID app run on)
If you need more information please contact us.