-1 making client authentication required at the access token endpoint
Client authentication is useful in some situations to raise the security
level. But requiring it will either keep out native apps or force there
developers to use useless/insecure secrets (I would call this "pseudo
security").
+1 making the client authentication required for certain client types.
for a definition of client types and there respective security
properties see http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10
In my opinion, the security considerations section already gives a clear
guideline when client authentication should be used and when the authz
server should rely on other mechanims.
regards,
Torsten.
Am 16.06.2011 17:08, schrieb Thomas Hardjono:
Apologies for the late response.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Wednesday, June 15, 2011 1:27 PM
To: OAuth WG
Subject: [OAUTH-WG] Client authentication requirement
Client authentication has been one of the main problem areas in OAuth
1.0 and 2.0 does nothing to resolve it (arguably, it makes it more
confusing).
Because of the desire to allow any client type in any deployment
environment, we ended up with a barely defined client authentication
model. We offer password-based client authentication using HTTP Basic
(and an alternative parameter), but leave it optional.
I would to suggest that perhaps we need a better definition of the "client" by
way of identifying one or two (or three) types of clients and listing their respective
security properties/capabilities. For example, if a client can/cannot keep cryptographic
keys (secrets), then say so. Similarly, if a client can do TLS but cannot do proper X509
processing, then list this, etc. etc.
In this way developers can at least map (in the minds) which client type
matches their deployment scenario, based on the best-match capabilities list.
I would like to go back to requiring client authentication for the
access token endpoint, using HTTP Basic or other schemes. To leave the
door open for clients incapable of authenticating to use the endpoint,
we will add a security consideration section discussing the
ramifications of using the access token endpoint without client
authentication.
This suggestions is linked to the topic of refresh tokens which I'll
post separately.
EHL
+1 agree that client authentication (to access token endpoint) should be made a
requirement.
/thomas/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
