实现OpenID Connect时能否在REST API头部或查询参数中传入用户名/密码？

Great question! Let’s break this down clearly since you’re working with an already functional OpenID Connect (OIDC) API using the Authorization Code Flow.

Short Answer #

Technically, you could modify your API to accept a username/password via request headers or query parameters, then manually validate those credentials against your auth server. But this is not recommended—it violates the core design of Authorization Code Flow, introduces major security risks, and breaks OIDC standards.

Why This Is a Bad Idea #

Let’s cover the key issues:

• Critical Security Risks:
  • Query parameters get logged in browser history, server access logs, and can leak via referrer headers—storing or transmitting passwords this way is extremely unsafe.
  • Even headers aren’t designed for this use case in Authorization Code Flow. If your API is called from a frontend, the password could still be exposed via browser dev tools or network monitoring.
• Breaks OIDC Flow Design:
  • Authorization Code Flow is built for user-centric authorization, where the auth server handles all user authentication (including MFA, consent prompts, session management). Skipping this redirect bypasses these critical security controls.
  • You lose the decoupling benefit of OIDC: your API shouldn’t handle direct password validation—that’s the auth server’s job. If the auth server ever changes its validation logic (e.g., adding password policies, switching to passkeys), your API will need to be rewritten.
• Maintainability Headaches:
  • Customizing the flow means you’re no longer following standard OIDC practices, making it harder to debug, onboard new developers, or integrate with other OIDC-compliant tools.

Better Alternatives #

Instead of hacking the Authorization Code Flow, use the right OIDC flow for your use case:

1. Client Credentials Flow (for service-to-service calls)
   • If your API is being called by another backend service (not a user-facing app), this is the correct flow. The client service uses its own client ID/secret to request an access token directly from the auth server, no user interaction needed.
2. Resource Owner Password Credentials (ROPC) Flow (last resort)
   • ROPC is an OIDC flow that allows clients to send a username/password directly to the auth server (not your API) to get an access token. This is only recommended if you fully trust the client (e.g., your own internal desktop app) and no other flow is feasible.
   • Important: ROPC skips many security features of OIDC (like consent prompts) and is deprecated in some contexts—use it sparingly, and only over HTTPS.

Final Takeaway #

Stick to standard OIDC flows instead of modifying Authorization Code Flow to accept passwords directly. It’ll keep your system secure, maintainable, and compliant with industry best practices.

内容的提问来源于stack exchange，提问作者Navjyot Kaur