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 <sberyoz...@gmail.com
<mailto:sberyoz...@gmail.com>> 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
<gffle...@aol.com <mailto:gffle...@aol.com>
<mailto: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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
