Things We Considered When Using FIDO with OpenID Connect
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:
- ID and password pairs are set when users create accounts
- The IDs and encrypted passwords are recorded in a server-side database
- 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:
- The servers only store public keys, so they don't store users' private information.
- The public keys are encrypted, which makes it much safer than using common keys.
- The users can log in without having to remember a password.
- 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:
- Achieving the necessary tuning and support in the current ID system
- 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:
- Analyzing ECC and RSA public keys (Goal 1)
- Taking the public keys created using biometric authentication and storing them in the RDS (Goal 1)
- Being able to correctly authenticate users when needed (Goal 1)
- Being able to support both web- and API-based paradigms (Goal 2)
Neat approaches we devised
- 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.
- Changing the programming language
Issues we encountered during the PoC
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.
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.
関連記事 | Related Posts
We are hiring!