Subject: [OAUTH-WG] Link header for 401 responses

From: Evert Pot <[email-masked]>
Date: Sat, 22 Sep 2018 14:47:01 -0400

Dear list,

Apologies if this has been brought up before. I searched the archives
but didn't find anything related.
I am working on a web application + api that uses OAuth2 implicit flow
and Bearer tokens.

It occurred to that when the API responds with a 401 request, a useful
addition would be that the api also informs the user of the OAuth2
authentication endpoint to redirect the user to.

It makes sense to me to do this via a HTTP Link header. A response could
look as follows:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
Link: <https://auth.example.org/authenticate> rel="oauth2-authenticate"

The reason I'm emailing is because I wanted to gauge whether this is
interesting, or if there are problems with this approach.

If it is interesting, I would like to take a stab at writing an IETF
draft for this.

Cheers,
Evert

---

From: Phil Hunt <[email-masked]>
Date: Sat, 22 Sep 2018 12:54:14 -0700

Evert,

See step “B” in sec 4.2 of RFC6749. The AS worries about  authenticating the user. 

Phil

> On Sep 22, 2018, at 11:47 AM, Evert Pot <[email-masked]> wrote:
> 
> Dear list,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Evert Pot <[email-masked]>
Date: Sat, 22 Sep 2018 22:06:27 -0400

Hi Phil,

I'm a little confused by this answer. The flow I'm interested in
supporting is a client connecting to a server and being able to
transparently discover an OAuth2 endpoint to obtain a Bearer token.
A feature like this might allow a generic client to access a service
without relying on out-of-band knowledge of which authorization server
belongs to which client resource.

---

From: Neil Madden <[email-masked]>
Date: Sun, 23 Sep 2018 06:31:17 +0100

UMA uses an as_uri property on the WWW-Authenticate header for this:

https://docs.kantarainitiative.org/uma/rec-uma-core.html#permission-success-to-client

Neil

> On 23 Sep 2018, at 03:06, Evert Pot <[email-masked]> wrote:
> 
> Hi Phil,
>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 24 Sep 2018 06:50:45 -0600

Hi Evert,

The working group recently adopted a draft called Distributed OAuth that
has more or less what you describe. Note that it's been adopted
https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM but
hasn't been published as a WG document yet so, for now, is found in this
individual draft
https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/

There are some security considerations that emerge with that kind approach
that need to be addressed. The aforementioned draft does attempt to address
them.

There's also been some discussion as to what the Link header should point
to (e.g. metadata document, issuer URL, authorization endpoint, token
endpoint). And even whether or not a Link header should be used vs. an
attribute on the WWW-Authenticate header. Most of those discussions should
be in the archives:
https://mailarchive.ietf.org/arch/browse/oauth/?q=Distributed+OAuth&gbt=1&index=m1TUuh7Tcha9tuDrCraIrkjy73o

So I guess to answer your question, there is interest in it and there is
already some work in the form of a draft. Your input into developing that
document would be welcomed.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Evert Pot <[email-masked]>
Date: Mon, 24 Sep 2018 10:09:45 -0400

Hi Brian,

This is *exactly* what I was looking for, thank you! I'll read the draft
and discussions and see if there's some way I can contribute.

Cheers,
Evert

On 09/24/2018 08:50 AM, Brian Campbell wrote:
> Hi Evert,
>
> The working group recently adopted a draft called Distributed OAuth
> that has more or less what you describe. Note that it's been adopted
> https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM
> but hasn't been published as a WG document yet so, for now, is found
> in this individual draft
> There are some security considerations that emerge with that kind
> approach that need to be addressed. The aforementioned draft does
> attempt to address them.
>
> There's also been some discussion as to what the Link header should
> point to (e.g. metadata document, issuer URL, authorization endpoint,
> token endpoint). And even whether or not a Link header should be used
> vs. an attribute on the WWW-Authenticate header. Most of those
> discussions should be in the archives:
> So I guess to answer your question, there is interest in it and there
> is already some work in the form of a draft. Your input into
> developing that document would be welcomed.
>
>
>
>
>
> On Sat, Sep 22, 2018 at 12:47 PM Evert Pot <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Dear list,
>
>     [email-masked] <mailto:[email-masked]>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly
> prohibited.  If you have received this communication in error, please
> notify the sender immediately by e-mail and delete the message and any
> file attachments from your computer. Thank you./

---

From: Neil Madden <[email-masked]>
Date: Mon, 24 Sep 2018 16:29:37 +0100

I missed the Link aspects of that draft. I would prefer to use the WWW-Authenticate header (as per UMA) for this rather than a Link header, for a number of reasons:

1) It makes the authenticate challenge self-contained. 

2) It allows more than one AS to be specified, by simply repeating the challenge with different parameters. For instance, when changing AS provider I might want to allow both for a short while: WWW-Authenticate: Bearer scope=“test”, as_uri=“https://as1.test”, Bearer scope=“test”, as_uri=“https://as2.test”. If we consider OpenID Connect then it is very common to allow multiple AS. 

3) It’s not clear to me what the Context-IRI of a Link header is on a 401 response. The spec (https://tools.ietf.org/html/rfc5988#section-5.2) says that it is “anonymous” on a 404 response, and it seems plausible that the same would apply on a 401 response - a resource server which takes pains to avoid information leakage about available resources might well respond with a blanket 401 response and then only issue a 404 after successful authentication. Maybe that’s ok, but it just feels odd - the link relation doesn’t seem well defined in this case. 

4) It allows a proxy to add its own AS uri as a Proxy-Authenticate header, independently of the main resource server’s AS. 

Cheers,

Neil

> On 24 Sep 2018, at 13:50, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> Hi Evert,
> 
> The working group recently adopted a draft called Distributed OAuth that has more or less what you describe. Note that it's been adopted https://mailarchive.ietf.org/arch/msg/oauth/pziAV_EEQ9L9xeXEgtdu5s07kLM but hasn't been published as a WG document yet so, for now, is found in this individual draft https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/
> 
> There are some security considerations that emerge with that kind approach that need to be addressed. The aforementioned draft does attempt to address them.
> 
> There's also been some discussion as to what the Link header should point to (e.g. metadata document, issuer URL, authorization endpoint, token endpoint). And even whether or not a Link header should be used vs. an attribute on the WWW-Authenticate header. Most of those discussions should be in the archives: https://mailarchive.ietf.org/arch/browse/oauth/?q=Distributed+OAuth&gbt=1&index=m1TUuh7Tcha9tuDrCraIrkjy73o
> 
> So I guess to answer your question, there is interest in it and there is already some work in the form of a draft. Your input into developing that document would be welcomed.
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.