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

{UPDATE} AA-BB-CC-DD-EE-FF 1001 Levels Hack Free Resources Generator

Find Ixinium (XXA) On Youtube

What is Cross-Site Request Forgery (CSRF)

Digital Banking — Why AML, Cybersecurity and Fraud are closer than you think.

Hijacking Kubernetes Services with Labels

How Tata Communications creates trustworthy connections

Reused key vulnerability in One-time pad for CTF

Apache Struts vulnerability leads to RCE

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

Ingress Nginx on Azure Kubernetes Service

Distributed Cache Systems and High Availability on Redis: vol. 1

The Chum Bucket: Thoughts about S3 buckets from an attackers perspective