help request: openid-connect different clients unexpectedly shared the same auth session

[RobWagMLP]

Description

Hi,
first of all, thanks a lot for that great piece of software. So far the only open source gateway that has (almost) all you need.
I am just facing one issue, that i am not sure about, if it is intended or if i might be doing something wrong.

I am having 2 apps, with a frontend and a backend each, running under different hosts.
These are handled in an apisisx-instance together with keycloak as idp and oidc-plugin.
my keycloak has 2 different clients, one for App A and one for App B.
I defined rules in apisix, to use the corresponding client-id and client-secret according to path and host.
So something like that:

- uri: /web/app1
          hosts:
            - app1.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_a}
              client_secret: ${client_secret_a}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: auth
              logout_path: /logout
              session: 
                secret: ${session_secret_a}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-web.domain.node_a": 1
1- uri: /api/*
          hosts:
            - app1.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_a}
              client_secret: ${client_secret_a}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: deny
              logout_path: /logout
              session: 
                secret: ${session_secret_a}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-api.domain.node_a": 1
              
 - uri: /web/app2
          hosts:
            - app2.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_b}
              client_secret: ${client_secret_b}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: auth
              session: 
                secret: ${session_secret_b}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-web.domain.node_b": 1
1- uri: /api/*
          hosts:
            hosts:
            - app2.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_b}
              client_secret: ${client_secret_b}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: deny
              session: 
                secret: ${session_secret_b}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-api.domain.node_b": 1

The behaviour i would have expected here, is that when logging into A, a session for A is created. And when accessing B, apisix would recognize that this is a different app with a different client and different session secret, and therefor the session from A should not be applied here and another login is enforced when accessing web2.

Instead i am simply also already logged in against B with the user from A.

The only way i can think of atm, to overcome this is running one apisix instance per application, but thats propably not how it should be.. So what i would like to have, is that a session is only valid for the client, we used for login, or some other way to configure the scope of session-validity. Easiest way would be to propably simply define the session-cookie name, that is checked against. As far as i can see cookies always identify like "session=", and if something like that is found, it is simply treated as authenticated. Using different session-secrets also didnt do the job.
So am i missing something here, or is this intended? And if not, could this be added? Would be a really helpful feature :)
Best regards
Robert

[kayx23]

Instead i am simply also already logged in against B with the user from A.

Can you describe this behaviour more in details? Is it like:

• visit /web/app1 and got a GUI auth page
• authenticate with user A
• visit /web/app2 and it does not ask for credentials while it should? (unexpected)

[RobWagMLP]

Yes of course, sorry if i was not precise enough.
So what i want is

• visit `/web/app1` and get KC GUI loginpage
  

• authenticate with user A
  

• visit `/web/app2` and get KC GUI loginpage
  

• authenticate with user B
  

instead it is like you described, user A is also logged in app2 , instead of beeing asked for credentials for app2.
Basically what i am asking for is an option to configure which routes belong to a session. So for example that i could say routes
/web/app1
and /api/* with host app1.mydomain.de get session_id A, and
/web/app2
and api* with host app2.mydomain.de get session_id B, so that if a user with session_id A comes to web/app2, he is not treated as authenticated.
Maybe thats already somewaht there and its a bug on my side, but so far i couldnt figure anything out that would trigger that behaviour. Already checked a bit of the code to to figure out if can make some plugin for myself here, but my lua-knowledge tends towards zero :\

[kayx23]

That is so very strange... Especially if you said using different session secrets also doesn't work as intended. I understand your issue now but I'm working on other things at the moment. I can surely circle back when I have time.

[RobWagMLP]

That would be really great.
The only way i could achieve that target is by having my kc-clients in different realms, wich is actually okay for the moment, but it would be really nice to be able to configure that a bit more independently from that.
I can provide you my full configuration if you want, its just a bit longer and the example i provided mirrors pretty well what i have there :)

[kayx23]

cc @shreemaan-abhishek

[damoshushu]

I encountered the same issue, and I had made a pull request #11286 to solve this problem. Test passed