Sergey, A hypermedia-driven (RESTful) API should be able to use OAuth. Unfortunately, OAuth does not have a RESTful design.
Most APIs require client apps (not just the user) to be pre-registered with the service. That seems to have made hypermedia-driven design less important - if a client app has to explicitly register with a service it may as well learn details like the authorization URI at registration time as well. 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. Before sending a AS-issued token to the original service the client app needs to know the AS trusts that service. Unfortunately this detail is missing from OAuth: tokens are issued with no indication of where they can safely be used [http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.4]. -- James Manger From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Wednesday, 16 May 2012 3:45 AM To: Sergey Shishkin Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request The danger is a bad resource, If that can redirect the client to a arbitrary AS to phish the resource owner's credentials that is a bad thing. The presumption is that the client knows where the trusted AS for that resource is, and if it needs to discover it that is a much bigger issue. In the IMAP case the client probably needs to do discovery on the identifier itself to figure out where to send the user. John B. On 2012-05-15, at 1:18 PM, Sergey Shishkin wrote: Bill, it might be me misreading the Implicit Grant Flow, but I understood it like this: 1. client tries to get a resource from server; 2. server redirects client to auth-service; 3. client authenticates against auth-service (HTTP Basic or whatever); 4. auth-service redirects client back to the resource; 5. client tries to get the resource providing the token. In step 3 the client is of course responsible for protecting its password from phishing, so auth-service should authenticate itself with a certificate. Am I right? If, yes my idea was to use this flow while choosing a standardized token - Bearer. But Bearer insists on 401 instead of redirects and that confused me. Sergey On Tue, May 15, 2012 at 6:24 PM, William Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> wrote: You can hard configure it into your client, that's safe. The problem comes when the client can be sent to an arbitrary, possibly phishing, site to do authentication. If the client supports the password grant then it probably just hands in the username and password without user interaction. -bill ________________________________ From: Sergey Shishkin <sergei.shish...@gmail.com<mailto:sergei.shish...@gmail.com>> To: William Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Sent: Tuesday, May 15, 2012 9:09 AM Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request In my scenario I control both the resource provider and the token issuer and I'm fine with the resource provider knowing the issuer. So, discovery is not needed. Or do I miss something? On Tue, May 15, 2012 at 6:04 PM, William Mills <wmi...@yahoo-inc.com<mailto:wmi...@yahoo-inc.com>> wrote: Yes, what you're running across here is the "discovery" problem. How do you discover the authentication endpoints for a service. Unfortunately it turns out returning that as part of the 401 has big security concerns. It's still being figured out. ________________________________ From: Sergey Shishkin <sergei.shish...@gmail.com<mailto:sergei.shish...@gmail.com>> To: oauth@ietf.org<mailto:oauth@ietf.org> Sent: Tuesday, May 15, 2012 5:12 AM Subject: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request While designing a hypermedia-driven API I'm evaluating possibilities to use OAuth Bearer tokens for claims-based authorization. Currently I struggle with how to communicate to the API client the way to obtain the token. In a hypermedia-driven manner I don't want the API client to get this information out of band, but rather let the client "just follow the links". The Bearer draft [http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-19#section-3] advises to send a 401 response with a WWW-Authenticate challenge specifying optional realm and scope. The problem here: neither realm nor scope identify the token issuer. The OAuth 2.0 draft [http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.1.1] suggests to redirect the resource owner to the token issuer, IIRC. I like this way from the hypermedia perspective, but still have mixed feelings about missed 401 and WWW-Authenticate challenge. Did I missed some part of draft covering my scenario? Are there any known grassroots implementations doing just that on the internet? Any opinion on the subject is very much appreciated. Thanks in advance, Sergey _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
