How to secure an authorization server without a public client or BFF pattern with KeyCloak?

I currently got an OAuth2 Resource Server configured - similar to Ch4mpy's set-up on GitHub. As for the OIDC Provider I'm using KeyCloak. Everything works so far - I can easily send my requests to the Authorization Server (KeyCloak) via e.g. Postman, get JWT and authenticate myself to access the resources I'm allowed according to the RBAC that I configured.

Now I'm heavily struggling with connecting my front-end applications with my back-end. In our system we got multiple apps (both B2B and B2C of nature - so different access points) and a variety of other front-end interfaces (like websites).

According to most documentations I now should either

1. use public clients for all interfaces that aren't able to store client secrets.
2. [or] use a BFF pattern for each front-end application.

Both aren't really feasible as the first suggestion would compromise security and the latter would require multiple servers to handle the communication.

Thus I've been thinking towards implementing a back-end that would get sufficient privileges (i.e. a confidential client) that sits in between all front-end applications and the authorization server. Unluckily, I wasn't able to find proper resources because with that matter comes new issues:

• How to secure the back-end application? (I.e. Make sure that no unauthorized calls can access it)
• How does the authentication flow work when a back-end server is in between these instances?
• How to integrate further IDPs (like Google Sign-In or Apple Sign-In) in this architecture?

All in all, how to "secure" the authorization server when not using a public client or a 1-on-1 BFF client for all front-end applications?

In your case, the "authorization server" is Keycloak. You don't provide Spring Security configuration for it. To prevent brute force, log login attempts, etc, refer to Keycloak documentation. Same for adding federated identity sources (like "social" login from Google or Facebook, but also a corporate LDAP or whatever).

A "backend in front of all the front-ends" is a BFF. BFF is configured as a confidential client and secures it's requests from front-ends with sessions. If you want to log authorization_code flow initiations, there, refer to the underlying middleware documentation (like spring-cloud-gateway if using it as BFF)

But I already explained that in the tutorials you are referring to...