DEV Community: Nikolay Poturnak

Launched - Passwordless login with one-click, biometric, or QR-code

Nikolay Poturnak — Thu, 06 May 2021 08:51:11 +0000

Excited to share! We launched idemeum - Passwordless Identity Platform. You can try idemeum and let us know what you think.

We are on product hunt.

https://www.producthunt.com/posts/idemeum

idemeum was born out of a simple thought - passwords suck👎. For users, they are hard to create, remember, and access quickly. For developers, they are expensive to manage, create unnecessary vulnerabilities, and add extra friction to user acquisition.

Today you have 2 choices - either struggle with passwords or give up your privacy for social login convenience. We thought users and developers shouldn't have to choose. So we asked a question - can we eliminate passwords and make the sign up experience easy, while keeping it private and secure?

That is how we created idemeum. idemeum is an identity platform for developers that is:

Passwordless - we replaced passwords with one-click, biometric, and QR-code login flows. You choose how you want to login your users - get simplicity of JWT token authentication with one-click, add extra security of WebAuthn with biometric login, or leverage mobile convenience and multi-factor security with QR-code login.

Private - we architected idemeum to be private by design. We do not want to be yet another party collecting your users' data. It is none of our business. We rely on client-side encryption to keep user data away from our eyes.

User centric - our goal is to make login experience invisible to users. Therefore, we made Single Sign-On a priority. And not just within one domain, but rather across apps. So that users login only once, and then they get truly frictionless experience accessing native mobile and web applications.

We are so excited to launch it today on Product Hunt, and we welcome all and any feedback you might have for us! Please let us know what you think about the product and its applicability, what features you might want us to add, and any questions that you might have.

Passwordless in 10 minutes - idemeum JavaScript SDK

Nikolay Poturnak — Tue, 27 Apr 2021 05:44:27 +0000

One SDK, 10 minutes of your time, and you can bootstrap passwordless auth for your single-page app. With one SDK, you get all the flows: one-click, WebAuthn, and QR-code login.

When we developed idemeum JavaScript SDK our goal was simple - provide you with a seamless intuitive integration experience, yet give you the flexibility to implement the login flows that you need. With one SDK and simple configuration you get it all - one-click, WebAuthn, or QR-code login experience. You choose what works best for your use case through simple developer portal settings.

idemeum JS SDK provides 4 methods to help you with your login needs: login, logout, userClaims, isLoggedIn. By leveraging these methods you can enable passwordless, secure, and private login for your application.

In this guide we will go through the following steps to implement passwordless login with idemeum JavaScript SDK:

Initialize idemeum SDK
Manage authentication state with isLoggedIn
Log the user in and out with login and logout
Get and validate user claims with userClaims

1. Initialize idemeum SDK

Basic HTML setup

Our application will display a simple log in button. Upon clicking a button, user will be authenticated by idemeum. After successful authentication idemeum will return ID and Access tokens to the application, and the user will be greeted.

As a first step, let's set up a simple index.html page that we will be using for our application. We will set up some very simple css styles in order to format how things are organized in our page.


<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>idemeum JS SDK</title>
    <link rel="stylesheet" type="text/css" href="/src/styles.css" />
  </head>
  <body>
    <h2>idemeum JS authentication sample</h2>
    <h4>Welcome to Application!</h4>
    <div id="initial">Loading...</div>
  </body>
</html>

And our simple styles.css file.

/* our css style sheet that we save in styles.css and then import in out index page */

body {
  font-family: sans-serif;
}

#initial {
  align-self: center;
  justify-self: center;
  background-color: #eee;
  text-align: center;
  width: 300px;
  padding: 27px 18px;
}

Import idemeum JS SDK

We can now import idemeum JavaScript SDK. For this guide we will simply import the script from idemeum CDN.

<script src="https://asset.idemeum.com/webapp/SDK/idemeum.js"></script>

Initialize idemeum SDK

We can now initialize idemeum SDK instance. Do not forget to use your clientId that you obtained from idemeum developer portal.

      var idemeum = new IdemeumManager(
        // 👇 Replace clientId with the the one you get from idemeum developer portal
        (clientId = "00000000-0000-0000-0000-000000000000")
      );

2. Manage user authentication state

idemeum SDK helps you manage authentication state of the user, so that you can determine if the user is logged in or not, and then take actions depending on the outcome. idemeum isLoggedIn returns Boolean value to identify the user authentication state.

In our application we will follow the following logic.

If the user is logged in, we will greet the user and display user claims.
In case the user is not logged in, we will not show any content and will simply display the login button.

As you can see in the code below, we are simply using login method for button onclick event.

      function isUserLoggedIn() {
        // Process the user logged-in state. 
        idemeum.isLoggedIn().then(
          function (data) {
            //  Display user claims if the user is logged in
            renderUserClaims();
          },
          function (errorData) {
            // Display the login button if the user is NOT logged in
            html = `<button id="btn-login" onclick="login()">Log in</button>`;
            document.getElementById("initial").innerHTML = html;
          }
        );
      }

And we can trigger isUserLoggedIn() simply when the body of the document loads.

   <body onload="isUserLoggedIn()">

3. Log the user in

When user clicks Log in button, idemeum SDK will trigger the login method. Let's define what will need to happen in our application. On success our application will receive ID and Access tokens from idemeum. We will need to process and validate those tokens. In case there is failure, we can process that as well in our code.

      function login() {
        idemeum.login({
          onSuccess: function (signinResponse) {
            // Your application will receive ID and Access tokens from idemeum
            // renderUserClaims() (defined below) validates the oidc token and fetches the user approved claims
            renderUserClaims();
          },
          onError: function (errorResponse) {
            // If there is an error you can process it here
          }
        });
      }

4. Get and validate user claims

idemeum SDK returns ID and Access tokens upon successful user login. For token validation you can:

Validate token yourself using any of the open source JWT token validation libraries.
Use idemeum SDK that provides userClaims method to validate tokens.

In our guide we will rely on idemeum SDKs to validate tokens and extract user identity claims. In the code below we will take user claims (first name, last name, and email), and we will display these claims when the user is logged in.

      function renderUserClaims() {
        idemeum
          .userClaims()
          .then(function (userClaimsResponse) {
            //fetch user approved claims from OIDC token
            htmlStart = `<div>
                          <p align="left">You are currently logged in.</p>
                          <pre id="ipt-user-profile" align="left">User profile:<br>`;
            htmlProfile =
              "<b><h3 style='color:Tomato;'>First Name:" +
              userClaimsResponse.given_name +
              "</h3></b><br>" +
              "<b><h3 style='color:Tomato;'>Last Name:" +
              userClaimsResponse.family_name +
              "</h3></b><br>" +
              "<b><h3 style='color:Tomato;'>Email:" +
              userClaimsResponse.email;

            htmlEnd = `
                    </pre>
                    </div>
                    <button id="btn-logout" onclick="idemeum.logout();isUserLoggedIn();">Log out</button>`;
            document.getElementById("initial").innerHTML =
              htmlStart + htmlProfile + htmlEnd;
          })
          .catch(function (errorResponse) {
            // If there is an error you can process it here
          });
      }

🎉 We are done with our simple SPA application!

You can check the full working code in CodeSandbox here.

You can check live demo of how you can authenticate users: one-click, WebAuthn, or QR-code.

At idemeum we build All-in-One Passwordless Identity Platform. We are happy to help you solve your sign up and login challenges.

Also published here.

All-in-one JavaScript SDK to make web apps passwordless

Nikolay Poturnak — Tue, 20 Apr 2021 21:10:22 +0000

Hey guys!

I built Passwordless Platform, and am looking for honest feedback to make the product useful.

I embraced on a journey to combine passwordless authentication with the power of Single Sing-On across apps:

I took what Auth0 is doing (set of SDKs and tools to outsource auth e2e)
Combined it with what social login is doing (SSO across domains and apps)
Added privacy so that only users have access to identity data
...and created idemeum.

Today I have JavaScript SDK that can integrate into your SPA app and enable 3 types of auth flows:

Let me know what you think. I will be happy to share working code examples of how to use JS SDK to go passwordless.

Live demo so you can play with auth experience.

https://jsdemo.idemeum.com

Passwordless Authentication Overview

Nikolay Poturnak — Sun, 28 Mar 2021 08:16:03 +0000

This technology guide will help us first take a look at the current state of password-based authentication, and then we'll dig into various technologies that can help you go passwordless with your apps.

Password-based world

Digital identity is so critical to everything we do online, yet it gets compromised in almost every cyber security breach. Every now and then we would hear the news and learn about yet another data breach where identity compromise would be at the core of it. But not everybody is willing to accept the simple truth - we are not equipped with the proper tools to protect our identity. We keep using old inefficient architectures and tools that have been invented decades ago.

First passwords probably arrived at the Massachusetts Institute of Technology in the mid-1960s, when researchers at the university built a massive time-sharing computer called CTSS. The punchline is that even then, passwords didn't protect users as well as they could have.

Fast forward 60 years and we are still using the same "strings of characters" that can ruin our lives and reveal everything about us. Your email. Your bank account. Your files. Your private photos. Your location. No matter how complex, no matter how unique, our passwords can no longer protect us. We constantly try to patch passwords, but we are unsuccessful. Take Multi-Factor Authentication as an example. Despite the obvious benefits, users are still leveraging it on a selective basis due to the significant user experience friction that it introduces.

At idemeum we believe patching passwords is no longer an option. We have to come up with simple, secure, and passwordless technology stack to handle our authentication online.

How passwords survived for that long

Using passwords to access online services is a commonplace experience and so are the user frustrations.

Passwords have survived for that long probably due to the three major reasons:

Simplicity - passwords are very simple to use. Type in characters, press a button, and you are in. No additional hardware required and no compatibility issues with pretty much any service online.
Ubiquity - passwords are everywhere. Unfortunately, they are like digital waste - everywhere we go, we leave a password behind. The experience of using passwords is so ingrained in our digital routine that there is no need to explain anyone how to use them. It is familiar and casual.
Replaceability - when compromised passwords are easy to replace. Unlike biometrics that are immutable, we can generate as many passwords as we want.

Why passwords need to go away

When one starts digging into real password experience and implications the reality becomes more disappointing.

Expensive - passwords are expensive for users and developers alike. Developers pay maintenance $ for storing, hashing, encrypting, and managing password infrastructure. Users pay productivity hours given the fact that passwords cause lock-outs, need to be reset frequently, and consume time with inevitable recovery flows.
Cause friction - yes typing password is simple. But looking at the overall lifecycle, we first need to create one, and with more and more stringent requirements (seven uppercase letters, four special characters, etc.) it is not an easy feat. But the real dance comes when you need to remember your password out of 100s of combinations that you already have 😤.
Wildly insecure - more than 80% of breaches are due to compromised credentials. The statistics is validating that hackers' tools are effective: phishing, spear phishing, brute forcing, rainbow tables, and many others are always there to aid in compromising your password.

The reality is that we are all annoyed by passwords. We've got dozens to remember, some of them annoyingly complex, and on any given day, as we read e-mails, send tweets, and order groceries online, we're bound to forget one, or at least mistype it. Moreover, we know passwords are going to compromised. That will happen sooner or later. And no one is going to enjoy it when that happens.

Passwordless world

Passwordless authentication (or “modern authentication,” as it is known in the industry) is the term used to describe a group of identity verification methods that don’t rely on passwords. Biometrics, security keys, certificates, and specialized mobile applications are all considered passwordless authentication methods.

We will now get deeper into each passwordless technology:

Certificate based authentication
Magic links
One-time passwords (OTPs)
Hardware tokens
Webauthn/FIDO2
Mobile as authenticator

1. Certificate based authentication

Certificate based authentication allows users to securely access an application by exchanging a digital certificate instead of a username and password.

To create a digital certificate, Public Key Infrastructure (PKI) 🔐 must be used. PKI allows for what is called an asymmetric encryption. Client generates two keys: private key that is kept secret by its owner, and public key that is disseminated widely and openly. Leveraging this asymmetric key pair, PKI enables:

Public key encryption - message is encrypted with a recipient's public key. For properly chosen and used algorithms, messages cannot in practice be decrypted by anyone who does not possess the matching private key.
Digital signatures - message is signed with the sender's private key and can be verified by anyone who has access to the sender's public key. This verification proves that the sender had access to the private key, and therefore is very likely to be the person associated with the public key. This also ensures that the message has not been tampered with, as a signature is mathematically bound to the message it originally was made from, and verification will fail for practically any other message, no matter how similar to the original message.

Client can then create a digital certificate that will conform to X.509 standard. X509 certificate will have various fields to identify the owner, including public key, subject name, validity period and others. The key here is that digital certificate needs be signed by some trusted 3rd party, so that this certificate can be trusted to represent identity of the owner.

In order to use digital certificate to authenticate to a target application, client will need to share a X.509 digital certificate with the application along with the proof of possession. Proof of possession will be represented by a nonce signed by a private key. When application receives the digital certificate, it can extract the user information from that certificate, and then will verify proof of possession to make sure that the requestor actually owns the private key.

Certificate based authentication is very popular in enterprise space due to the fact that most employee devices are managed with MDM, and it is convenient and easy to provision certificates to client devices.

However, certificate based authentication is not as prevalent in consumer and developer space, as it is quite complex to install and manage X.509 certificates on unmanaged user devices. Some vendors try to create mobile and desktop applications that aim to simplify certificate provisioning and management, but the user experience will still be complex for ordinary users.

2. Magic links

With magic links an application sends a unique URL link to user's email address or mobile phone via SMS. There is no need to enter any credentials. Instead, the user clicks on the magic link to authenticate. Since the magic link includes unique one-time authentication token, the user is logged in and redirected to an application landing page.

Magic links enable great frictionless experience for the users as there are no credentials to remember and very few steps to perform.

However, we believe that to provide best possible experience magic links need to be combined with cross app Single Sign-On, so that when the users verify their email with magic link they can maintain the session and seamlessly login across applications.

3. One-time passwords (OTPs)

OTPs are heavily used in multi-factor authentication flows, but one-time passwords or one-time codes can also be used as a standalone authentication method.

OTPs are time-bound numeric codes linked to a reference.

One-time passwords function via random algorithms that create a new and random code each time access is requested.
These codes are sent to a user upon providing a reference (email address or phone number). When the user enters the code back to a target application, the user is authenticated.
As soon as the OTP enables access to the account, its validity comes to an end. Since an OTP (a four or six-digit numerical PIN code in most instances) can be entered just once, it’s not as risky as static passwords that can be used multiple times.

The biggest advantage offered by OTPs in contrast to standalone passwords is that they’re safe from replay attacks. In plain language, an adversary who uses trickery to capture your OTP can’t reapply it, since it’s no longer valid for future logins or sessions.

4. Hardware tokens

A hardware security token is a physical device that validates user’s identity and grants access to the target application or resource. The user must possess this token to complete the authentication process. Hardware tokens can be used as a primary authentication method, or used in combination with other authentication factors such as username and password.

Hardware tokens come in many forms, most commonly as USB tokens, key fobs, and wireless Bluetooth tokens. Also, there are three main types of hardware tokens.

Connected tokens - a user must plug the security token into the system, computer, cardholder, etc. to complete the verification. Two examples of this type of token includes a USB token and a Common Access Card (CAC), the latter of which requires the use of a CAC reader.

Disconnected tokens - these are the small devices that look like a sim card, keychain fob, or USB flash drive. These tokens generate a unique and temporary cryptographic code that must be input by the user to gain access to a computer resource.

Contactless tokens - with contactless tokens, you don’t need to connect to a device or enter any access codes. Instead, contactless devices connect with the system wirelessly. Based on the connection’s credentials, the system either grants or denies access. The most noteworthy examples of contactless tokens are Bluetooth tokens.

5. Webauthn / FIDO2

The Web Authentication API (also known as WebAuthn) is a specification written by the W3C and FIDO, with the participation of Google, Mozilla, Microsoft, Yubico, and others. The API allows servers to register and authenticate users using public key cryptography instead of a password.

WebAuthn is part of the FIDO2 framework, which is a set of technologies that enable passwordless authentication between servers, browsers, and authenticators. Today WebAuthn is supported by major browsers, including Chrome, Firefox, Edge, and Safari.

Webauthn allows applications to integrate with strong biometric authenticators built into end user devices, like Windows Hello or Apple’s Touch ID. Instead of a password, a private-public key-pair (known as a credential) is created for a website. The private key is stored securely on the user’s device; a public key and randomly generated credential ID is sent to the server for storage. The server can then use that public key to prove the user’s identity.

Let's first look at the major components required to enable passwordless authentication with Webauthn.

Webauthn API - common and public API implemented by all major browsers that provide a mechanism to interact with FIDO based authenticators. This API defines registration, meaning enrollment of a credential, and authentication methods.
FIDO2 server - FIDO2 implementation in the application's backend. FIDO2 server calls browser based Webauthn API in order to communicate with the platform or roaming authenticator.
CTAP - Client to Authenticator Protocol. CTAP defines how the FIDO client running on a specific platform, e.g. an operating system or a web browser, can talk to an external authenticator such as a USB-powered security key or a mobile phone that can interact with the computer via NFC or Bluetooth.
FIDO authenticator - hardware based authenticator (USB device or built-in biometric sensor) that protects that user private key with which the authentication is performed.

Here is the high level flow to show how Webauthn authentication is performed on the web.

Webauthn registration

First a user proves his identity with some other means, such as proving ownership of an email (using magic link), or uploading ID document for online identity proofing.
FIDO2 server starts the registration process by calling Webauthn browser API with the registration request.
Webauthn API communicates with FIDO authenticator over CTAP to create scoped credentials for the user.
Private key will be stored with authenticator and public key will be passed to the application backend. Response to the FIDO2 backend server will include various attributes including public key, attestation, and client data.
Application backend will store the public key and associate it with the identity of the user.

Webauthn authentication

User requests access to the application.
FIDO2 communicates with the Webauthn API using authentication method and passing the authentication challenge.
Webauthn API passes the request to authenticate and challenge to FIDO authenticator using CTAP protocol.
User is prompted to use biometrics to unlock access to authenticator private key.
Upon success, challenge is signed with the user private key by FIDO2 authenticator and is passed back to application backend.
Application validates the signed challenge with the user public key and grants access to the user.

Webauthn is the modern authentication protocol that is currently undergoing broader adoption across website and browsers. It offers strong passwordless authentication for the users, however as you can see it is not solving enrollment / registration step. To provide complete frictionless experience to users Webauthn needs to be paired with other tools such as magic link or online identity proofing to address user enrollment

You can try Webauthn demo here.

6. Mobile as authenticator

The last passwordless method we wanted to cover is using your mobile phone as an authenticator. It is also called Passwordless MFA as it combines multiple authentication factors together:

Something you have - you mobile phone and certificate that resides on your mobile device.
Something you are - mobile device biometric sensor, such as Face ID or Touch ID.

There are various implementations that we have seen in the industry, but we believe that the best and most secure implementation should be leveraging FIDO and Hardware Backed Security on a mobile device. Meaning that authentication shall be driven by FIDO protocol, and both iOS and Android support FIDO today. And the FIDO private keys need to be protected by HSM modules on mobile devices (Secure Enclave on iOS or TEE / StrongBox on Android).

The most typical authentication flow is to install and leverage a mobile app that will handle authentication.

User requests access to an application.
QR-code is displayed instead of asking user for any input. There are various possibilities here - for instance asking for email and then sending push notification, but we find QR-code providing the most seamless experience.
User scans the QR code with mobile app.
Application triggers FIDO based authentication.
User authenticates with a biometric sensor on a mobile device.
The application verifies the authentication response according to FIDO spec and grants access to the user.

Final thoughts

When we talk about Passwordless Authentication we immediately think and focus on authentication only. However, we need to think about user digital identity journey holistically - how will users enroll into our identity system, how will we authenticate them strongly yet providing great experience, and how will we let users manage and maintain their digital identity.

At idemeum we believe that at this day and age there are 3 major requirements for implementing a successful login system for a modern application:

It needs to be passwordless - no more passwords, no more compromises, no more frustrated users who are overwhelmed with account creation.
It needs to offer Single Sign-On - users need to login once and be able to access any application they want without any boundaries. No one wants to verify his email or enroll a new FIDO key with every new application sign up.
It needs to guarantee privacy - privacy is becoming ever more important in our digital world. Digital identity is critical and it needs to be owned and controlled by users, and not monetized by 3rd party companies.

At idemeum we build All-in-One Passwordless Identity Platform. We are happy to help you solve your sign up and login challenges.

Also published here.