On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan <joseph at authlete.com> wrote:
> It may be worth slightly rewording 7.2 as it may encourage a growing misconception that all native apps must be public clients. With many devices now having embedded HSMs, we’ve seen increasing interest in mobile apps being dynamically (per-install) registered oauth2 private clients, and that model has a lot of advantages. (I’m not sure if we might see a similar model evolving for web apps.)
That's a great point, thanks. I've removed the reference to native apps being public clients since it doesn't really add anything to this spec if I have to caveat the description.
On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <torsten at lodderstedt.net> wrote:
> > > First of all the AS decides whether it issues refresh tokens or not. Having the ability does not mean the AS must do it. If you feel it’s safer to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats doc or in this proposed best practice doc). Not all end developers using these protocols fully understand the ramifications.
> @Aaron: I suggest this goes to the SPA BCP since this is client specific.
Thanks, I agree that this document should include some recommendations around refresh token handling. Looking at the discussion in this thread, it seems there are a few different strategies folks are taking. Since it seems like there isn't a strong consensus, it sounds like this would be better suited for the "Security Considerations" section, and to not make MUST/SHOULD recommendations, but rather just point out the issues. Any thoughts on that before I take a stab at writing something?
I've incorporated some of the other feedback here and published an updated version:
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01
Thanks for the feedback so far.
WeChat ID
aaronpk_tv
