Should IDM be private or exposed for app login?
In the diagram below, I have two options for authenticating into a protected resource. Both options use an Identity & Access Management (IDM) tool (in this case keycloak) to store credentials and present as a JWT once properly authenticated. The only real difference between both methods is where the IDM (keycloak) sits and thus where it is exposed. In option 1, the IDM is private and not exposed to the internet (but only exposed to the application doing the authentication) whereas in option 2, the IDM is exposed publicly such that the application redirects to the IDM to handle all of the authentication.
On the surface it seems pretty logical to protect such a crucial piece of software infrastructure (the IDM) but then why would Keycloak in particular advertise/support such a robust login page?
Which option is preferred for security?
I am not familiar with the acronym "IDM", but for this answer I will assume it means the same as an Identity Provider (IdP) in the SAML / OIDC sense.
The only difference I can see between those diagrams is whether you use your login page, or keycloak's login page.
I see your concern that Option 1 exposes the IdP to direct attack, but isn't your login page just a shallow skin for the keycloak login page? What are you really hiding? Do you believe that your developers can build a better and more robust login page than the keycloak developers?
Also consider also these points:
- With Option 2, your application never handles passwords, which can save you substantial engineering effort to harden and protect them. Also, if you are in an audited environment, being able to say "We don't handle passwords, and here are keycloak's security certifications" is a much easier story to tell.
- With Option 2, you can configure your app to accept 3rd party identities that your app should not ever see the password for -- for example if you allow partners to log in to your platform by authenticating against your partner's Active Directory. Same if you want to allow users to link their Google or Facebook accounts, etc.
- Sometimes the fact that the client (browser) can reach the IdP is actually an important piece of information; for example if the IdP is in a backend prod network or a corporate network (ex.: ADFS in front of the prod AD), then redirecting their browser to the IdP proves that the client is also VPN'd into the backend network.
Summary: I don't see a security upside by replacing the IdP vendor's login page with your own; and actually a lot of security downside if the login page you build is less robust than the one built by a security specialty vendor. Also, Option 2 gives a lot more deployment flexibility, which you can leverage for increased security.