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 > <[email protected]> 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. > > > > > >> On Sat, Sep 22, 2018 at 12:47 PM Evert Pot <[email protected]> wrote: >> 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 >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > 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. > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
