Spec Violations in GitHub OAuth Implementation and Security Considerations

Spec Violations

  1. The response_type request parameter of authorization request is missing. The parameter is mandatory. See RFC 6749 (The OAuth 2.0 Authorization Framework) Section 4.1.1 (Authorization Request).
  2. The default format of token response seems application/x-www-form-urlencoded. The format must always be application/json. See RFC 6749 (The OAuth 2.0 Authorization Framework) Section 5.1 (Successful Response).
  3. Values in the scope response parameter in token response are “comma-delimited”. The delimiter must be “space”. See RFC 6749 (The OAuth 2.0 Authorization Framework) Section 3.3 (Access Token Scope).
  4. The format of the Authorization header for resource access is Authorization: token OAUTH-TOKEN although the token response says "token_type":"bearer". The format must be Authorization: Bearer OAUTH-TOKEN. See RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) Section 2.1 (Authorization Request Header Field).
  5. The default format of device authorization response seems application/x-www-form-urlencoded. The format must always be application/json. See RFC 8628 (OAuth 2.0 Device Authorization Grant) Section 3.2 (Device Authorization Response).
  6. The default format of token response in the device flow seems application/x-www-form-urlencoded. The format must always be application/json. See RFC 8628 (OAuth 2.0 Device Authorization Grant) Section 3.5 (Device Access Token Response). The section states “If the user has approved the grant, the token endpoint responds with a success response defined in Section 5.1 of [RFC6749];”
  7. Values in the scope response parameter in token response in the device flow are “comma-delimited”. The delimiter must be “space”. RFC 8628 requires that token endpoint implementations conform to RFC 6749.

GitHub-Specific Extensions

  1. The login parameter of authorization request. Instead of introducing the GitHub-specific parameter, it is better to utilize the login_hint parameter which is defined in OpenID Connect Core 1.0 Section 3.1.2.1 (Authentication Request).
  2. The allow_signup parameter of authorization request. Instead of introducing the GitHub-specific parameter, it is better to utilize prompt=create which is defined in Initiating User Registration via OpenID Connect.
  3. The token endpoint changes its response format according to the Accept header in the token request. No. The response format must always be application/json.
  4. The device authorization endpoint changes its response format according to the Accept header in the device authorization request. No. The response format must always be application/json.
  5. The following error codes that the token endpoint may return in the device flow are GitHub-specific. They are not defined in the standard specifications; incorrect_client_credentials, incorrect_device_code, device_flow_disabled

Security Considerations

  1. Should support RFC 7636 (Proof Key for Code Exchange by OAuth Public Clients). To be concrete, the authorization endpoint should support the code_challenge and code_challenge_method request parameters and the token endpoint should support the code_verifier request parameter. The specification prevents attackers from exchanging a stolen authorization code with an access token at the token endpoint. Read Proof Key for Code Exchange (RFC 7636) for details about the specification.
  2. Should support RFC 8705 (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens) Section 3 (Mutual-TLS Client Certificate-Bound Access Tokens). If GitHub had supported the “certificate binding” specification, the impact of the security incident (Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators) could have been drastically mitigated. The specification prevents attackers from using a stolen access token for resource access unless they have succeeded in stoling the client certificate of the victim client application, too. Read Financial-grade API, explained by an implementer for explanation about certificate binding.
  3. Should support securer client authentication methods at the token endpoint and the device authorization endpoint. In the traditional client authentication methods explained in the Section 2.3 (Client Authentication) of RFC 6749, the client secret is sent over the network. It should be avoided. As a matter of fact, the Financial-grade API specification prohibits the traditional client authentication methods. Read OAuth 2.0 Client Authentication for details about securer client authentication methods.
  4. Many other security enhancement specifications have been developed since RFC 6749 was published in October, 2012, which is about 10 years ago! For example, JAR (RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)), JARM (Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)) and PAR (RFC 9216 OAuth 2.0 Pushed Authorization Requests). Should consult experts in Working Groups of OpenID Foundation.

--

--

--

Co-founder and representative director of Authlete, Inc., working as a software engineer since 1997. https://www.authlete.com/

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Install Nuclei on Kali Linux

Metasploit

What is a Fire OS Kiosk Lockdown Software?

Password Managers sound boring. But you need to get one in 2017.

MAZE Report 10.25 — 11.17

Scrypt-Adaptive-Nfactor

A.I. for Cybersecurity Is a Hot New Thing — and a Dangerous Gamble

TOP SECURITY CONCERNS, BEST PRACTICES AND KEY SECURITY FINDINGS — 2021 IN REVIEW

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Takahiko Kawasaki

Takahiko Kawasaki

Co-founder and representative director of Authlete, Inc., working as a software engineer since 1997. https://www.authlete.com/

More from Medium

SAST in Secure SDLC: 3 reasons to integrate it in a DevSecOps pipeline

Kubernetes: Same Domain SSL with DNS Verification using Let’s Encrypt

From Design-First to Automated Deployment with OpenAPI — Kubeshop

How the k8s Gateway API enables Multi-cluster Backend development