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.
On 09/22/2018 03:54 PM, Phil Hunt wrote: > 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 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
