Keycloak: Role based client log-in access restriction for users

I am trying to achieve fairly simple usecase of role based client application (VueJS multi-page applications) control using the keycloak.

As shown in image, I have three different roles and three different clients in single realm.
The arrow in the image represents which role can access which client.

So my main objectives are,

• User with role Viewer should only be able to log-in to the Viewer Application. If the same user tries to access the Operator Application or Admin application then keycloak should simply deny this user from doing so.
• The same rules should follow for users with Admin and Operator role. Users of Admin role should be able to log-in to any of these application by keycloak.

To achieve this usecase I tried following ways,

• First by appropriate role mapping to users and role creation in the clients. In this case, I create realm level roles and then client level roles, then assigned appropriate roles to the users created in the user section.
• Enabling the Authorization. In the policies, I removed default policy that grant all users access to the client. And create a User policy and Client policy to restrict the access to client application
• Also tried with Group based authorization policy. In this case, I created a group with client role and then assigned user to these groups. And enabled them from the Authorization group policy.

But, unfortunately none of this works. Meaning my user with Viewer role can log-in to my admin application. Which is just strange.

The solution proposed by @Stuck is a great start, but it has a significant flaw: When the user has already authenticated, e.g. via the standard flow of another client that did not require the role, the password form flow will never be triggered. Consequently, the user will be logged in via the cookie flow without ever checking for the role.

In other words: If there are other clients (such as the account console) that do not require the role, anyone can bypass the role check.

To fix this there needs to be an additional flow layer that includes all authentication executions, that is followed by the authorization step (no matter what authentication flow was used). The final result will look like this: