PiyushMishra318 commented on PR #13038: URL: https://github.com/apache/apisix/pull/13038#issuecomment-4087697499
> Hi @PiyushMishra318, thank you for your contribution and the effort you put into this! > > After reviewing the approach, I have some concerns that I think warrant a different direction: > > 1. **Core layer modification concern**: Adding JWT decoding logic into core/ctx.lua introduces unsigned JWT parsing at the core routing layer. This could have unintended security implications since it bypasses signature verification. > 2. **Better alternative exists**: The same goal (routing to different consumers based on JWT issuer) can be achieved using APISIX existing mechanisms - multiple routes with vars conditions to match different issuers, or the built-in consumer and consumer_group mechanism with the existing openid-connect plugin. > 3. **File scope mismatch**: The PR modifies FAQ.md and radixtree-uri-vars tests rather than the openid-connect plugin itself, which suggests the changes may not be targeting the right layer. > > Since this is still in draft status, I would recommend exploring the route-based approach using vars conditions - it would achieve the same result without modifying the core context. Happy to discuss further if you would like to explore that direction! Thanks for your feedback @moonming. We did explore the vars-based routing approach using the http-x-tenant header for our use case, but it didn’t fully solve the problem for us. Similarly, with the consumer/consumer_group approach, our understanding is that consumer resolution happens after authentication succeeds, which makes it difficult to dynamically switch auth strategies based on the JWT issuer. One of the main reasons we considered APISIX was to avoid maintaining a bespoke multi-auth/realm handling system. However, as we scaled to more auth scopes, the configuration complexity grew significantly, which is what led us to experiment with a core-level change. That said, I completely understand your concern around introducing unsigned JWT parsing at the core layer, especially from a general security standpoint. In our case, since these APIs are primarily internal, we may consider maintaining this as an internal patch instead of pushing it upstream. I do think native support for this kind of use case in APISIX would be valuable in the future—ideally with a more robust and secure approach than what we proposed here. Happy to discuss or explore alternative directions if there’s a recommended pattern we might have missed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
