No web clients often make use of sticky grants. Sharing client_id amongst multiple instances is a native app thing, but stick grants work best with confidential clients.
It is to some extent a UI decision by the AS, to tell the user you have already granted A & B , they are asking to add C, or re-prompt the user for A, B and C without giving the context. The other thing to consider is implicit clients without refresh tokens. If the client is JS in the browser then if you remember the grants the JS can do a prompt=none flow to refresh an expired AT in the background as long as the browser has a session with the AS. If you are using an implicit client and don’t support sticky grants, you wind up having to have AT that have a lifetime grater than what is optimal. John B. > On Jan 27, 2016, at 1:07 PM, Thomas Broyer <t.bro...@gmail.com> wrote: > > > > On Wed, Jan 27, 2016 at 1:54 PM George Fletcher <gffle...@aol.com > <mailto:gffle...@aol.com>> wrote: > The difference might be whether you want to store the scope consent by client > "instance" vs client_id application "class". > > Correct me if I'm wrong but this only makes sense for "native apps", not for > web apps, right? > (of course, now with "installable web apps" –e.g. progressive web apps–, > lines get blurry; any suggestion how you'd do it then? cookies?) > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
