Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

[Sergey Beryozkin <[e-mail]>]

Hi

On 27/01/16 17:47, William Denniss wrote:
> In our implementation we mostly record grants as per-user,
> per-client_id. However, we treat public clients whose identity we can't
> verify as ineligible for incremental auth. The reason is if a client is
> counterfeiting another client, we don't want to return previous
> authorizations (the user should at least have to grant permissions in
> the context of this other counterfeiting application).  For a public
> client where the return path can be guaranteed by the OS (e.g. Universal
> Links on iOS), this rule can be relaxed, so it's more about public
> clients whose identity cannot be verified (e.g. custom URI scheme, or
> localhost redirect).
>
> I have an idea for how to solve those unverifiable clients too, where
> the client would prove its previous authorization grant by providing the
> current access token on the new "incremental" authorization request.
>
> For verifiable clients, we have an option to "snowball" tokens and
> include previous grants (with the exception of some scopes that need
> per-device approval), using the non-standard param
> include_granted_scopes
> <https://developers.google.com/identity/protocols/OAuth2WebServer#incrementalAuth>.
> Such a request results in a new token being issued with potentially
> increased scope, we don't automatically increase the scope of previously
> issued tokens.
>
> Perhaps this group could consider standardizing Incremental OAuth. There
> are valuable lessons & techniques that several people here have learnt
> and implemented over the years, as shown by this thread. I might be
> willing to put together a draft.

IMHO it would be very useful, +1

Thanks, Sergey

>
>
>
> On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Hi George
>
>     Thanks. I think I'll need to spend more time on thinking about the
>     way it has to be implemented, but I guess one thing I realize is
>     that using only access tokens as records for this purpose is not
>     ideal/generic.
>
>     That said, it is not clear to me that a per-instance level consent
>     makes sense only when the dynamic registration is used.
>
>     Suppose we have a statically registered client, with the client id
>     shared between 100 devices or even confidential clients. I'm
>     actually not sure how realistic it is that the same user works with
>     more than one device sharing the same id, but assuming it is
>     possible sometimes, and further, with incremental authentication in
>     place,
>
>     we can have a situation where while working on device1 a user has
>     approved 'a' while on device2 - scope "b", with both devices sharing
>     the same client id.
>
>     May be I'm making it too complex :-)
>
>     Thanks, Sergey
>
>     On 27/01/16 16:53, George Fletcher wrote:
>
>         My recommendation, like the others, is to store consent by
>         client_id:user and then try and leverage dynamic client
>         registration if
>         instance level consent is needed.
>
>         On 1/27/16 11:43 AM, George Fletcher wrote:
>
>             Yes, I was thinking mostly of "native apps"... though you
>             bring up a
>             good point. It would be great if "installable" web apps could do
>             dynamic client registration:)  I suppose for a "public"
>             client that is
>             loaded onto a device, the "installation" process could
>             obtain a new
>             client_id for that instance. Cookies might work, or have the app
>             generate a unique identifier and use that in conjunction
>             with the
>             client_id?
>
>             Thanks,
>             George
>
>             On 1/27/16 11:07 AM, Thomas Broyer wrote:
>
>
>
>                 On Wed, Jan 27, 2016 at 1:54 PM George Fletcher
>                 <[e-mail] <mailto:[e-mail]>
>                 <mailto:[e-mail] <mailto:[e-mail]>>> 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
>             [e-mail] <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>     --
>     Sergey Beryozkin
>
>     Talend Community Coders
>     http://coders.talend.com/
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/oauth
>
>