Baoyuantop commented on issue #11514:
URL: https://github.com/apache/apisix/issues/11514#issuecomment-4088722415

   Good question. In APISIX, `type = 'auth'` is not a general label meaning 
"this plugin does authentication." It is a specific framework-level marker with 
strict technical requirements:
   
   1. **Consumer binding**: Auth-type plugins must define a `consumer_schema` 
so that credentials (API keys, JWT secrets, etc.) can be configured on 
[Consumers](https://apisix.apache.org/docs/apisix/terminology/consumer/). At 
request time, the plugin extracts the credential, looks up the matching 
Consumer, and binds it to the request context. This is how APISIX knows *which 
consumer* is making the request.
   
   2. **Simple rewrite contract**: Auth-type plugins run in the `rewrite` phase 
and follow a simple contract — return `nil` on success (pass-through) or return 
an HTTP status code on failure. This is what `multi-auth` relies on to iterate 
through plugins.
   
   The `openid-connect` plugin works fundamentally differently:
   - It does **not** bind to Consumers (no `consumer_schema`) — it delegates 
identity verification entirely to an external IdP.
   - Its `rewrite` phase involves complex flows: HTTP 302 redirects to the IdP, 
callback handling, session/cookie management, token introspection, etc. This 
doesn't fit the simple success/failure contract that `multi-auth` expects.
   
   So while OIDC absolutely does authentication in the general sense, its 
architecture is incompatible with the `type = 'auth'` plugin contract in 
APISIX. That's the reason it can't be used with `multi-auth`.
   
   As a workaround, you can use separate routes with different `vars` 
conditions to route requests to different authentication methods, as described 
[above](https://github.com/apache/apisix/issues/11514#issuecomment-2623695639). 
Alternatively, if you only use `bearer_only` mode (token introspection without 
the redirect flow), a custom plugin approach is also feasible.


-- 
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]

Reply via email to