是否可无需client_secret通过Github OAuth获取access token？

Short answer: No, GitHub's OAuth 2.0 implementation does not support obtaining an access token without a client_secret, even for public clients like mobile apps or browser-based SPAs that can't securely store secrets.

Let me break this down clearly:

• GitHub's OAuth implementation constraints: While OAuth 2.0 specifications recommend omitting client secrets for untrusted clients, GitHub has chosen to enforce client_secret usage across all its supported OAuth flows. It doesn't support the Implicit Grant flow (historically used for SPAs without secrets) and requires the secret even when using the Authorization Code flow—this applies to native/mobile apps too, despite RFC guidance to the contrary.

• Secure alternative for public clients: PKCE: For clients that can't safely store client_secret (like mobile apps), GitHub supports the PKCE (Proof Key for Code Exchange) extension to the Authorization Code flow. This lets you avoid exposing the secret while maintaining strong security:

  1. Generate a random code_verifier string directly on the client device.
  2. Create a code_challenge by hashing the code_verifier with SHA-256, then encoding it with base64url.
  3. Include the code_challenge and code_challenge_method=S256 in your authorization request to GitHub.
  4. When exchanging the authorization code for an access token, send the original code_verifier along with your client_id and client_secret.
     Even if an attacker intercepts the authorization code, they can't exchange it for a token without the matching code_verifier.

• Why GitHub requires client_secret: GitHub's approach prioritizes verifying the identity of the client making the token request to prevent abuse, even if it deviates from some general OAuth recommendations for public clients. Their official documentation explicitly states that the client_secret is mandatory when exchanging the authorization code for an access token.

So while the OAuth 2.0 framework allows for secret-less flows, GitHub's implementation doesn't support them. Your best bet is to use the Authorization Code flow with PKCE to securely handle token exchanges in untrusted client environments.

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