Hi, I've seem some implementations where the token is not directly delivered to the browser by the backend, but some temporary UUID that later the SPA can exchange for an access token.
Do you think this is a good approach to the recommendation you are discussing? In addition to that, could you clarify more what would be the limitations that ASes may wish to impose to these clients? Regards. Pedro Igor On Tue, Apr 2, 2019 at 1:10 PM George Fletcher <gffletch= 40aol....@dmarc.ietf.org> wrote: > I think it's fair to call it out (either in the paragraph here or in the > security considerations). The issue is that the security aspect of the > access token ending up in the browser is probably true in many contexts > other than SPAs:) > > What about something like... > > In this scenario, the backend component is likely a confidential client > which is issued it's own client secret. Note that in this model, the > access_token obtained by the backend component will be delivered to the > browser for use by the SPA so is more exposed than in the classic > confidential client model. Some Authorization Servers may wish to limit the > capabilities of these clients due to risk considerations. > > ... or something like that. > > On 4/2/19 11:57 AM, Aaron Parecki wrote: > > Thanks, this is a good question. I was talking with someone about this > draft the other day and had the same question myself. Re-reading RFC6749, > "public client" does describe only the limitation of the client protecting > its own credentials, so I think you're right that this paragraph is > misleading. However I suspect that some ASs will still want to treat > clients where the access token ends up in the browser differently. Is that > a fair assessment? I think the fix to this paragraph would be a slight > rewording to just remove the mention of public clients. > > Aaron > > > On Tue, Apr 2, 2019 at 8:53 AM George Fletcher <gffle...@aol.com> wrote: > >> Hi, >> >> In section 6.2 the following statement is made... >> >> In this scenario, the backend component may be a confidential client >> which is issued its own client secret. Despite this, there are still >> some ways in which this application is effectively a public client, >> as the end result is the application's code is still running in the >> browser and visible to the user. >> >> >> I'm curious as to how this model is different from many existing resource >> server deployments acting as confidential clients. While the application >> code is running in the browser, only the access token is exposed to the >> browser as is the case for many RS deployments where the RS returns the >> access token to the browser after the authorization flow completes. My >> interpretation of "confidential client" does not include whether the >> client's code is "visible" to externals or not, but rather whether the >> client can protect the secret. >> >> In that sense I don't believe this deployment model is "effectively a >> public client". A hybrid model description is fine, and I don't disagree >> that some authorization servers may want to treat these clients in a >> different way. >> >> Thanks, >> George >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk <http://twitter.com/aaronpk> > > > _______________________________________________ > 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
