Multiple Kong Authentication methods on a single route?

1

I don’t think this will work OOTB with Kong. The anonymous user function is a backdoor to allow unauthenticated calls to still pass. But say I wanted to authenticate both OAuth2.0 CC pattern AND HS256 generated JWT client creds via Kong plugins for consumers.

My first thoughts are make a new plugin on the side(call it multi-auth or w/e). Then have in the handler a check of the authorization header and depending on its length(Oauth vs jwt, oauth2 has a shorter token length 100% of the time) invoke the handlers of the oauth2 / jwt plugin code? But that does not make sense because the plugins themselves need to be on the route too right(with their own conf’s)?

So maybe I need to add OAuth2 + JWT plugins on the route AND a multi-auth plugin that runs before the both of them to then invoke the other plugins handler methods manually(which will then pick up their independent conf’s right?) Ofc multi auth plugin would in theory also need to check and see if the auth header is present and respond with a 401 or w/e if it isn’t and such for some error handling(or just default to oauth2 handler or something for missing header call).

Wish there was an elegant way to support both easily but this makes sense to me based on existing architecture, figured I would get any Kong/community feedback. Anyone else doing this now? Kinda curious what it looks like invoking other enabled plugins from another plugin on a given route/service if anyone has done so.

Edit - Ooo but if I leave the standard auth plugins enabled they would each run after the multi-auth in an unpredictable pattern… maybe add them to the route but leave the jwt / oauth plugins “disabled” so only the multi auth truly runs but the conf for each plugin would still be in the context of the multi-auth handler calls of the other plugins? Hmm maybe even this would not work and I literally have to write a frankenstine of both plugin logic combined… which would be super gross.

2

So I realized the mistakes of my ways, the Kong documentation does provide a way to do this OOTB on services or route resources: https://docs.konghq.com/1.4.x/auth/#multiple-authentication

I tested it in a slightly different manner than their base docs discuss(where it makes no mention of ACL being able to shot circuit the tx, but focuses on using the request termination plugin to stop the tx if anonymous user post auth plugin invocations).

Took a route, threw on the OAuth2 CC Flow, HS256 JWT and ACL plugin on this proxy.

Added no auth header, saw 403 unavailable(ACL plugin stopped the call cause my anonymous configured user did not have the whitelist group needed). Maybe an enhancement could be if the ACL plugin is enabled on a route and the anonymous user is in the context(can acl plugin have awareness to that? Then maybe it could 401 instead?). But works nonetheless.

Then tested with an OAuth token and got 200 success with a authorized consumer(not the anonymous user) and tested with JWT and got 200 success with a valid authorized consumer. At first I thought the anonymous user concept ootb was going to always allow user access but I now realize its a decent solution to the issue of mulitple auth for a single proxy.

My next investigations will be if I can make my OIDC plugin(which is 3rd party auth) IF successful NOT have the ACL plugin get invoked at all. Or maybe I could hard force some anonymous user context groups to the whitelist id value contained in the acl plugin FROM the OIDC plugin prior to hitting the ACL plugin logic(to prevent the ACL plugin from throwing the 403)? Idk. Would be neat to be able to do programmatic AND user auth browser session type plugins on the same proxy path too. Getting around the ACL plugin blocking those OIDC calls will be tricky tho, need to noodle it a bit :grinning: .