Introduction

Hello. Ryo here, an ID Platform developer in the Global Development Group. KINTO services have already been rolled out in several countries, and we're planning to spread them to even further afield. Our mission in the ID Platform Development Team is to create an ID system that enables customers all over the world to use all of KINTO's services smoothly with a single ID, from any country. Today, I'd like to tell you about our FIDO proof of concept (PoC).

Identity provider/ ID provider, or IDP

An identity provider / ID provider (IdP or IDP for short) is a system entity that creates, maintains, and manages principal identity information, and provides authentication services for dependent applications in a federated or distributed network. A concept like the "identity provider / ID provider" above (IDP from here on) might be difficult to understand if you've never heard of it before, but to put it simply, it's a system that manages, authenticates, and authorizes users.

---

Overview of FIDO

Maybe you know what FIDO (Fast IDentity Online) is already, but in case you don't, it's a new authentication standard that — unlike the ordinary ID and password authentication methods— is all about doing password-free ID authentication for online services. It uses a key pair consisting of a private key and a public key, which is a more secure approach than the ordinary one based on sharing a common key.

---

FIDO authentication procedure

The procedure for registering is as follows:

Login procedure for registered users

---

Comparison with the ordinary way

The ordinary way:

1. ID and password pairs are set when users create accounts
2. The IDs and encrypted passwords are recorded in a server-side database
3. The server gets sent IDs and passwords, and is asked to decide if they're correct

Pros of FIDO authentication

FIDO authentication is a new password-free, secure authentication method that enables authentication to be done via public key cryptography instead of using passwords. It has the following advantages for users:

1. The servers only store public keys, so they don't store users' private information.
2. The public keys are encrypted, which makes it much safer than using common keys.
3. The users can log in without having to remember a password.
4. Fingerprint and face authentication are more convenient than manually entering passwords.

---

What we have achieved

Broadly speaking, we had the following 2 goals for our FIDO PoC:

1. Achieving the necessary tuning and support in the current ID system
2. Coming up with a plan that will enable us to easily adopt FIDO for both internal and external ID systems if desired.

In line with these goals, we successfully achieved the following 4 things:

1. Analyzing ECC and RSA public keys (Goal 1)
2. Taking the public keys created using biometric authentication and storing them in the RDS (Goal 1)
3. Being able to correctly authenticate users when needed (Goal 1)
4. Being able to support both web- and API-based paradigms (Goal 2)

---

Neat approaches we devised

1. Covering both web- and API-based paradigms in the basic design stage

Rather than simply creating an IDP, we also want to deploy it globally as KINTO's IDP, and get it used for other services as well. For KINTO's services, we're going for easy adoption of FIDO functionality with an API-based paradigm, and we're envisaging being able to adopt it for other companies' ones as well, using a web-based, one-click paradigm. If we can figure out neat ways to support both of these, it'll become more convenient.

2. Changing the programming language

The sample code we got from the official website is written in JavaScript for both the frontend and the backend. We're deploying services with Spring Boot, so if we want to add it to the IDP as a new feature, we'll need to change it from JavaScript to Java. If there's no Java library with the same functionality as the external JavaScript-based one, we'll need to do some coding in order to make the change.

Issues we encountered during the PoC

When authenticating a user, a bug sometimes arose where the public key didn't match the one stored in the RDS. On trying to debug it, we found that the public key IDs stored in RDS were encoded as base64, but the Java and JavaScript base64 encoding functions were giving different results. We'd run it in JavaScript with auto-padding off, but when we moved the backend logic to Java, the auto-padding setting didn't get picked up, and the Java auto-padding got used anyway. Turning off auto-padding fixed the bug. + Base64.getUrlEncoder().encodeToString(ID string) - For patterns using auto-padding, the part of the encoding result that's less than a multiple of 4 gets automatically padded with equals signs ("=") + Base64.getUrlEncoder().withoutPadding().encodeToString(ID string) - With auto-padding off, the encoding result gets left as is.

---

Problems

FIDO has made it easier and more convenient for users to use online services securely, but there are still a few things that need to be taken care of.

Public key management issue:

• Multiple public keys can be added on the same device

The server can't tell whether the same device is being used, so you can register a public key the same device as many times as you like. This means garbage data gets stored in the RDS.

• Reregistering public keys by switching devices, etc.

If you lose your device, get a new one, etc., you need to do the FIDO registration again. When you reregister, you need to verify your identity another way. This is less convenient than with ID-and-password authentication.

• Managing unwanted public keys

The above will result in unwanted public keys. Users can't manage their public key IDs, so the backend can't tell whether public keys are valid when they become unwanted. Public keys still have to be stored on the RDS for a long time even if they become invalid.

---

Summary

We wanted to give users a better password-free experience with authentication, so we decided to do a PoC for FIDO. As a result, we feel that it's a powerful solution but there are still issues with things like public key management. So, we want to continue to develop things having soundly verified that they're suitable.

References

What is FIDO Authentication? What is OpenID Connect?