Security implications of using Keycloak as an REST API and avoiding Keycloak forms all together?

Question

I'm currently working on a project where we are using OpenID Connect and Oauth2 with Keycloak's default forms.

We have requirements to implement 2FA. In an ideal world we'd scrap the keycloak forms all together and just use keycloak as a headless API and build the login forms in the main application itself.

The reasons being

• We have components built in Vue.js we would like to re-use (e.g. password/code inputs, password strength indicator etc)
• We don't want to maintain the same styles in two different projects
• We don't want to maintain or be limited by custom templates
• Don't want to write custom behaviour in vanilla js

After doing research I've found that using keycloak as an API is not recommended because the redirection between the client and 3rd party login acts as an additional layer of security, and is part of the OAuth2.0 model. We're storing users medical information so security is a concern.

What would you guys suggest?

Answer 1

You are right that using an OAuth server through an API is not recommended. Redirects are an important part of the security of an OAuth flow. This of course creates all the drawbacks that you mentioned - having to maintain multiple codebases with the same functionality.

A solution to this problem is to use hypermedia API with strong security mechanisms, which can be used to perform OAuth flows. Unfortunately this is not a standard yet, and it is an emerging feature. You can read how such an API works here and here you can find an in-depth description of the security features of an implementation we did at Curity.

It will definitely not be an easy task to implement it in Keycloak currently, but there most probably there is no other option to solve this problem - as you said you need 2FA, without 2FA an option is to use the Resource Owner Password Flow.