hyperscale-stack / security / 38048066397

95%

master: 95%

Pull #95

github

fix(oauth2): refuse client authentication with an empty secret

client_secret_basic decoded "Basic base64(<client_id>:)" into an empty
secret and handed it to the client's SecretMatcher, and
DefaultClient.SecretMatches matched it against an empty Secret. Anyone
who knew the client_id of a client registered without a secret — a
public client, or a confidential or untyped one left without one —
authenticated as it at /token and /revoke, and at /introspect when it
was confidential, which the confidential-only check of #81 let through.
client_secret_post never accepted an empty client_secret, so the two
secret methods disagreed.

An empty secret is no credential. RFC 6749 §2.3 lets the authorization
server accept the client authentication meeting its security
requirements and forbids relying on a public client's authentication to
identify it, and OAuth 2.1 §2.1 calls clients without credentials
"public clients". RFC 6749 §2.3.1 lets a client omit an empty
client_secret, but requires Basic only for clients "that were issued a
client password". client_secret_basic now refuses a missing client_id
or an empty password with 401 invalid_client before loading the client,
with the guard client_secret_post's Authenticate already has: no store
lookup, one answer for every client. DefaultClient.SecretMatches never
matches an empty Secret, and the SecretMatcher contract says
implementations MUST NOT match an empty secret: callers of DefaultClient
are covered, custom matchers are told to follow suit.

Public clients that sent an empty Basic password must send their
client_id in the form body (none); confidential or untyped clients
registered without a secret need one to use client_secret_basic or
client_secret_post. CHANGELOG and MIGRATION.md describe the change.
Refs #94.

6 of 6 new or added lines in 2 files covered. (100.0%)

4840 of 5108 relevant lines covered (94.75%)

75.86 hits per line