> The problem is the password grant. This doesn’t sound like a good reason to ditch AS discovery via an WWW-Authenticate response header. Client apps using the password grant are only a subset of OAuth clients, and a specialized subset at that. The spec [draft-ietf-oauth-v2-26#section-4.3] says the “authorization server should take special care when enabling this grant type, and only allow it when other flows are not viable”. Just tell those few “highly privileged” client apps using the password grant not to use AS discovery via an WWW-Authenticate response if it is a problem (though I’m not sure it is any worse than a resource returning WWW-Authenticate: BASIC ... to trigger the password being sent?).
-- James Manger From: William Mills [mailto:wmi...@yahoo-inc.com] Sent: Thursday, 17 May 2012 12:29 AM To: Manger, James H; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request The problem is the password grant. Clients that support it would potentially deliver the username and password without asking the user, or by prompting in the UI itself and not through a web interaction with the AS. ________________________________ From: "Manger, James H" <james.h.man...@team.telstra.com> To: William Mills <wmi...@yahoo-inc.com>; "oauth@ietf.org" <oauth@ietf.org> Sent: Wednesday, May 16, 2012 5:55 AM Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request Bill, >> A WWW-Authenticate response header that identifies an authorization >> server (AS) would be a great hypermedia-driven solution. >> It tells the client app which AS a service trusts. >> The client app can then get a token. ... > Yeah, unfortunately the WWW-Authenticate solution advertising an AS > has bad (fatal) security problems. Is phishing the fatal security problem? It doesn't sound quite like "normal" phishing. Are there still fatal problems if phishing-resistant user authentication mechanisms are used? I would really appreciate any further explanation (or pointers to explanations). > That's the underlying reason/urgency behind a separate services > discovery mechanism. It's not that we ignored WWW-Authenticate, > and in fact I'm in process of ripping that mechanism out of a > draft I'm working on. > > This is not hard when the protected resource or user identifier > is in a domain where WebFinger (WF) will work. Is this because we assume a domain controls its webfinger URI, but we don't want to assume a domain controls all its other URIs (perhaps because some will serve user-generated content)? > The problem comes when we have, for example, N email domain names > all served by the same AS, and you have to discover that way. > The solution there may be that you take an indirect path through > the MX record (one suggestion), determine the domain from that, > and do the WF lookup based on the MX domain. This doesn't sound like Sergey’s situation where the client app has made a web request -- so it knows the URI it wants. > For arbitrary webservices running on a domain where they can't > run their own WF endpoint we don't yet have a solution. > At some point the client may well be expected to know something > about the identity it expects to use for a site. Could you clarify "the identity it expects to use for a site"? I'm not sure if this is talking about the user's identity, the client app's identity or the site's identity. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
