Only for confidential clients. No authentication is required for public clients.
On Tue, Sep 19, 2017 at 4:47 PM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > Except a refresh token is not purely bearer. The client is required to > authenticate to use it. > > Phil > > > On Sep 19, 2017, at 2:33 PM, Bill Burke <bbu...@redhat.com> wrote: > > > > I'd be curious to the response to this too. > > > > Seems to me that refresh token has the same possible security risks in > > an Angular app as an access token, except the refresh token is valid > > longer....Still, if you did the implicit flow, you'd have to have > > longer access token timeouts as it would be really annoying for the > > user to have to login again and again in a long session with your > > Angular app. > > > > We have a javascript adapter that does Authz Code Flow with PKCE for > > our Angular app. It also does CORS checks on the code to token XHR > > request just in case on the IDP side. > > > >> On Tue, Sep 19, 2017 at 9:27 AM, Stefan Büringer <sbuerin...@gmail.com> > wrote: > >> Hi, > >> > >> there were some discussions in January regarding recommendations for > >> browser-based apps > >> (https://www.ietf.org/mail-archive/web/oauth/current/msg16874.html). > >> > >> I'd just like to ask if the Authorization Code Flow with PKCE is a valid > >> option for Single-Page-Applications (in our case Angular), because > Implicit > >> Flow cannot be used in our scenario. > >> > >> Authorization Code Flow with PKCE eliminates the necessity for client > >> secrets, but our concern is that exposing the refresh token to the SPA > might > >> be a security risk, compared to the Implicit Flow were no refresh token > is > >> exposed. > >> > >> What's your take on this? > >> > >> Kind regards, > >> Stefan Büringer > >> > >> P.S. I couldn't find that much on the internet regarding Authorization > Code > >> Flow with PKCE in SPAs, if you have some recommendations for good blog > posts > >> I would be grateful. > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > -- > > Bill Burke > > Red Hat > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
