Markdown Version | Session Recording

Session Date/Time: 14 May 2024 16:00

OAUTH

Summary

This OAUTH Working Group session focused on the OAUTH 2.1 specification, specifically reviewing GitHub issues related to current best practices and clarifications. The primary goal of OAUTH 2.1 is to consolidate existing specifications and provide a clearer, simpler understanding of OAUTH without introducing new mechanisms. Key discussions revolved around the case-insensitivity of the "Bearer" scheme, resolving interoperability issues with client authentication methods (HTTP Basic vs. POST body), and addressing potential conflicts with OpenID Connect scope definitions. Decisions were made to clarify existing ambiguities and update recommendations based on current implementation experience. One issue regarding HTTPS redirects as identity proof was deferred due to time constraints.

Key Discussion Points

• Bearer Scheme Case Sensitivity:
  • The current OAUTH 2.0 specification examples and ABNF for the Authorization header's "Bearer" scheme use a capital 'B'.
  • However, ABNF strings are technically case-insensitive, leading to confusion and some implementations (incorrectly) treating "Bearer" as case-sensitive.
  • A poll of the room indicated a strong preference for clarifying the specification.
  • The OpenID Connect conformance suite already tests both upper and lower-case "Bearer".
• Client Authentication Method Interoperability (HTTP Basic vs. POST Body):
  • The existing OAUTH 2.0 specification for client authentication via HTTP Basic (Authorization header) requires a complex double-encoding (URL-encode then Base64-encode client secret) that has led to widespread interoperability problems, especially with special characters in secrets.
  • Client authentication via the POST body (using client_id and client_secret parameters) does not suffer from these encoding issues and is widely supported by existing identity providers and clients.
  • The current specification states that POST body authentication is "not recommended", a historical preference based on using standard HTTP mechanisms.
  • Discussions indicated that many modern clients and servers default to or prefer the POST body method for its reliability.
  • A strong sentiment emerged to steer implementers towards the more robust POST body method and provide historical context for the issues with HTTP Basic.
• Conflicting OpenID Connect Scope Definitions:
  • OAUTH itself does not define scopes; OpenID Connect (OIDC) defines several commonly used scopes (e.g., profile).
  • A concern was raised that an OAUTH Authorization Server, not implementing OIDC, could define scopes with the same names but different meanings, leading to confusion for clients.
  • The discussion highlighted that other identity protocols also define scopes, making a generic normative statement difficult to enforce without impacting unrelated specifications.
  • A sense of those present indicated that a non-normative recommendation would be more appropriate.
• HTTPS Redirects as Identity Proof for Native Apps:
  • Language in the native app section discussing "claimed HTTPS redirects as identity proof" was flagged as potentially misleading, suggesting it could be used for general client authentication rather than its intended purpose of skipping the consent screen.
  • This issue was briefly introduced but deferred due to time constraints.

Decisions and Action Items

• Bearer Scheme Case Sensitivity:
  • Decision: The specification will keep the examples and ABNF definition using a capital 'B' for "Bearer". An explicit sentence will be added to the specification clarifying that the "Bearer" scheme in the Authorization header is case-insensitive.
  • Action Item: Aaron Parecki to update the text in the OAUTH 2.1 draft.
• Client Authentication Method Interoperability:
  • Decision:
    1. The paragraph in the specification stating that sending client credentials in the POST body is "not recommended" will be removed.
    2. The text will be updated to state that an Authorization Server MUST support client credentials in the POST body.
    3. The text will be updated to state that an Authorization Server MAY support client credentials using HTTP Basic authentication.
    4. A new paragraph will be added to describe the historical interoperability problems and encoding complexities associated with client secret basic authentication.
    5. The order of presentation will be adjusted to emphasize the POST body method.
  • Action Item: Aaron Parecki to update the text in the OAUTH 2.1 draft.
• Conflicting OpenID Connect Scope Definitions:
  • Decision: Non-normative text will be added to the specification. This text will mention the existence of OpenID Connect scopes and include a non-normative recommendation (using "recommended" in lowercase) against defining conflicting scope definitions.
  • Action Item: Aaron Parecki to add non-normative text to the OAUTH 2.1 draft.

Next Steps

• The issue regarding "HTTPS Redirects as Identity Proof for Native Apps" (issue 164) was deferred.
• Aaron Parecki and the Working Group chairs will discuss offline whether another interim meeting is warranted to address remaining OAUTH 2.1 issues or if these can be handled during the upcoming Vancouver IETF meeting.