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.