I don't think the leak of client IDs is a big issue, in any cleartext protocol
you can just sniff them. We don't mandate SSL on the protected resources.
Anyone relying on ClientID for a stronger assurance will want to be using SSL
and an unguessable ID anyway.
________________________________
From: Mike Jones <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Monday, December 12, 2011 4:51 PM
Subject: [OAUTH-WG] Using OAuth error_code to glean information from the server
I recently received an inquiry regarding invalid_client vs. invalid_grant. It
seems that there is a potential information disclosure in the specification
with respect to how these error codes are used:
invalid_client
Client authentication failed (e.g. unknown client, no
client authentication included, or unsupported
authentication method). The authorization server MAY
return an HTTP 401 (Unauthorized) status code to indicate
which HTTP authentication schemes are supported. If the
client attempted to authenticate via the "Authorization"
request header field, the authorization server MUST
respond with an HTTP 401 (Unauthorized) status code, and
include the "WWW-Authenticate" response header field
matching the authentication scheme used by the client.
invalid_grant
The provided authorization grant (e.g. authorization
code, resource owner credentials, client credentials) is
invalid, expired, revoked, does not match the redirection
URI used in the authorization request, or was issued to
another client.
If one uses invalid_client when the client is unknown and invalid_grant when
the client credentials are invalid, then an attacker could deduce whether or
not a particular client exists.
First, do people agree that this is a potential information leak and that the
leak is meaningful? If so, what mitigation might be suggested? For instance,
might a server choose to use a single error code for both (and potentially
other) cases?
Thanks,
-- Mike
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
