Ugh sorry, rephrase:
"I don't think there is a need for authenticated clients if you're
doing..."
On 3/2/2014 5:24 PM, Bill Burke wrote:
A good read:
http://tools.ietf.org/html/rfc6749#section-3.2.1
I was thinking about our current client-secret requirement. I don't
think there is any security hole if you are doing the OAuth protocol
over SSL, you are validating redirect_uris and the client sends its
"client_id" when obtaining an access token.
* Keycloak server ensures the access code is transmitted to a valid site
by verifying/validating the redirect_uri sent.
* Since you're using HTTPS, the browser ensures the site is valid by
checking it's cert.
* If you send the "client_id" when obtaining the access token, the auth
server can verify that there was no access code substitution.
One of the uses described in 3.2.1 is that it is easier to reset a
client's credentials than invalidating all the refresh tokens sent to
it. I'm not so sure that is true. If there were a per-app/per-oauth
client Not-Before setting, we could check this on a refresh request.
Any counter arguments to these assumptions? I'm going to see if anybody
on the oauth email list will verify these assumptions.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com