How to use the openid-connect plugin with upstream APIs?

Hi,

I’m struggling to understand how to setup/configure the OIDC plugin with Kong with backend APIs.

If my Client is unsecured, any API calls that it makes through Kong will get a 302 which then is redirected to the OIDC provider for the user to login. However, with an API client, it will simply follow the 302 (by default) and the returned value will not at all match what is expected, and therefore cause an exception in my client’s logic.

For example, my client is trying to access:
GET https://myapi.com/user/1 which is supposed to return JSON: { "username": "eric" }

if it submits an unauthenticated request, Kong will return:
302 Location: https://keycloak.oidc/auth/realms/MYAPI/protocol/openid-connect/auth

But if my API client follows the 302, the data returned from the auth endpoint does not match the expected values at all and will cause an error in my client.

How am I supposed to configure either my API client or Kong to avoid this problem? Disabling 302 redirects by the client makes no sense, so I suspect there must be a way to configure the Kong plugin to return a 401 instead?

Thanks,

Eric

This line:

But if my API client follows the 302, the data returned from the auth endpoint does not match the expected values at all and will cause an error in my client.

Has you asking some fairly fundamental oauth2 questions. openid-connect is returning you a 302 probably because you’ve setup an unauthorized_redirect_uri on the plugin, allowing you to redirect unauthorized requests to your configured IdP.

The openid-connect plugin has several different modes of operation which can come into play depending on your setup. If you just want to return 401 if the user doesn’t provide a sufficient Bearer or Introspection authorization token, you could restrict auth_methods to just those two methods, set anonymous to be the consumer ID of a specific, not actual user, then attach the exit-transformer plugin to the anonymous consumer, returning 401.

I went through the configuration and none of the redirect URLs were configured, so I was expecting a 401 and not a 302. I wanted to paste the full config here, but here is the extract of the critical *redirect* parameters.

            "forbidden_redirect_uri": null,
            "login_redirect_mode": "fragment",
            "login_redirect_uri": null,
            "logout_redirect_uri": null,
            "redirect_uri": null,
            "session_redis_cluster_maxredirections": null,
            "unauthorized_redirect_uri": null,
            "unexpected_redirect_uri": null,

Similarly, my auth_methods are limited as well:

            "auth_methods": [
                "bearer",
                "authorization_code",
                "refresh_token",
                "session"
            ],

I tried to dig through the documentation a little bit more to understand the config.consumer_claim, config.consumer_optional and config.anonymous work together and am somewhat confused by your recommendation. From my understanding of the docs, the anonymous will only be evaluated if consumer_claim is enabled and not found. Yet if there is not token (ie: no auth), then will anonymous even be used? Won’t the plugin simply return 302?

OpenID Connect plugin | Kong
If the Consumer is not found and config.consumer_claim is defined, you can use this value to fallback to an anonymous Consumer. Set this value to id of the Consumer to which you want to fallback. If fallback fails, 401 will be returned.

Thanks,

Eric

We only use the bearer and introspection auth_methods in conjunction with the consumer_claim config at my company, and I think the anonymous user comes into play regardless of whether or not the request includes auth. This plugin is so complicated though that it’s possible that even though I use this in production I don’t quite understand it.

We’ll probably need someone from Kong to confirm intended behavior here.

Thanks,

Will probably have to play around with the different configs a lot, but was hoping this would be a lot more straightforward. This OIDC plugin is great in concept; I just can’t figure out how to configure it properly.

Thanks,

Eric


© 2019 Kong Inc.    Terms  •  Privacy  •  FAQ