Subject: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

From: Sergey Shishkin <[email-masked]>
Date: Tue, 15 May 2012 14:12:42 +0200

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

---

From: Justin Richer <[email-masked]>
Date: Tue, 15 May 2012 09:45:26 -0400

This kind of fully automated approach isn't solved yet. OAuth isn't 
quite as simple as HTTP Basic and its kin, where the user agent can 
collect everything it needs directly and just push it back to the 
protected URL. In order for this to truly work, you need to have not 
just a pointer to the issuer, but a full dynamic registration and 
service discovery stack that the client knows about. For starters, the 
Client needs to know the Authorization Endpoint and Token Endpoint for 
the service, as well as which flows it supports. You'd probably want to 
know what kinds of token are supported, too. The authorization server 
needs to issue a Client ID and (probably) Client Secret to the Client to 
allow it to request tokens at all. Defining those is out of scope for 
the core specs, but there's some new work that's getting started around 
Host Meta (for discovery) and a dynamic client registration spec that 
will address some of the biggest parts of this.

  -- Justin

On 05/15/2012 08:12 AM, Sergey Shishkin wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Shishkin <[email-masked]>
Date: Tue, 15 May 2012 17:40:31 +0200

Justin,

I want to let client (API client, not OAuth Client) know less to get the
job done. The service should ideally be able to encode everything required
in a URL and give it to the client. This is what is described in the
Implicit Grant Flow [
http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-4.2], right? So,
why does Bearer spec insist on 401?

Sergey

On Tue, May 15, 2012 at 3:45 PM, Justin Richer <[email-masked]> wrote:

>  This kind of fully automated approach isn't solved yet. OAuth isn't quite
> as simple as HTTP Basic and its kin, where the user agent can collect
> everything it needs directly and just push it back to the protected URL. In
> order for this to truly work, you need to have not just a pointer to the
> issuer, but a full dynamic registration and service discovery stack that
> the client knows about. For starters, the Client needs to know the
> Authorization Endpoint and Token Endpoint for the service, as well as which
> flows it supports. You'd probably want to know what kinds of token are
> supported, too. The authorization server needs to issue a Client ID and
> (probably) Client Secret to the Client to allow it to request tokens at
> all. Defining those is out of scope for the core specs, but there's some
> new work that's getting started around Host Meta (for discovery) and a
> dynamic client registration spec that will address some of the biggest
> parts of this.
>
>  -- Justin
>
>
> 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
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: William Mills <[email-masked]>
Date: Tue, 15 May 2012 09:04:24 -0700 (PDT)

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 <[email-masked]>
>To: [email-masked] 
>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

---

From: Sergey Shishkin <[email-masked]>
Date: Tue, 15 May 2012 18:09:48 +0200

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 <[email-masked]> 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 <[email-masked]>
> *To:* [email-masked]
> *Sent:* Tuesday, May 15, 2012 5:12 AM
> *Subject:* [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
>

---

From: William Mills <[email-masked]>
Date: Tue, 15 May 2012 09:24:17 -0700 (PDT)

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

>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>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?
>
>

---

From: Sergey Shishkin <[email-masked]>
Date: Tue, 15 May 2012 19:18:16 +0200

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 <[email-masked]> 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
>
> *To:* William Mills <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Tuesday, May 15, 2012 9:09 AM
> *Subject:* Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated
> request
>
> On Tue, May 15, 2012 at 6:04 PM, William Mills <[email-masked]>wrote:
>

---

From: John Bradley <[email-masked]>
Date: Tue, 15 May 2012 13:45:19 -0400

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:
> 
> 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
>

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 16 May 2012 15:30:13 +1000

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: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, 16 May 2012 3:45 AM
To: Sergey Shishkin
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

John B.

Bill,

Sergey

On Tue, May 15, 2012 at 6:24 PM, William Mills <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Sent: Tuesday, May 15, 2012 5:12 AM
Subject: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

Thanks in advance,
Sergey

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Tue, 15 May 2012 23:12:01 -0700 (PDT)

Yeah, unfortunately the WWW-Authenticate solution advertising an AS has bad (fatal) security problems.  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.  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.

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 somehting about the identity it expects to use for a site.

-bill

> From: "Manger, James H" <[email-masked]>
>To: Sergey Shishkin <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Tuesday, May 15, 2012 10:30 PM
>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.
> 
>From:[email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
>>From:Sergey Shishkin <[email-masked]>
>>To:William Mills <[email-masked]> 
>>>From:Sergey Shishkin <[email-masked]>
>>>To: [email-masked]

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 16 May 2012 22:55:21 +1000

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

---

From: William Mills <[email-masked]>
Date: Wed, 16 May 2012 07:29:11 -0700 (PDT)

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.

>To: William Mills <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, May 16, 2012 5:55 AM
>Subject: RE: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request
> 
>Bill,
>

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 17 May 2012 10:33:22 +1000

> 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:[email-masked]]
Sent: Thursday, 17 May 2012 12:29 AM
To: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] OAuth Bearer: Response to an unauthenticated request

Bill,

--
James Manger

---

From: William Mills <[email-masked]>
Date: Wed, 16 May 2012 20:06:31 -0700 (PDT)

The problem is not with the auth servers, it's with clients that support password grant.  If they trust info sent to them by a resource server they will give up the goods.

>Sent: Wednesday, May 16, 2012 5:33 PM
>From:William Mills [mailto:[email-masked]] 
>>From:"Manger, James H" <[email-masked]>