Hi
Re the confidential client: let me explain please how we experimented
with this feature when the code flow is used.
1. Client requests a scope 'a' for a given User, it gets approved by the
user, the clients gets a code and exchanges it for a token.
2. At some later stage Client requests a scope 'b' for the same user and
if an access token for a given Client + User combination exists and the
incremental authorization is supported (we use a different term for now)
than the service finds out from this token that 'a' has already been
approved and offers a consent screen where a user sees 'a' being
selected and needs to approve 'b'.
3. User approves 'b'. The client gets a new code back and exchanges it
for a new token which now has "a" and "b".
At this point a client has 2 tokens, one with the "a" scope and another
with the "a" and "b" scopes and the assumption was that the client would
itself remove the now redundant token with the scope "a" only.
I've just updated the code for the service itself do it on the client's
behalf, optionally remove the scope "a" token so that the client can
simply replace a reference to its scope "a" token with the new one
(scopes "a" and "b") it will get after exchanging a code grant.
Is it an incremental authorization or something else completely :-) ?
One obvious difference, apart from the lower level implementation
details, is that it is not a client which requests to include the
already authorized scopes but the service does it itself if the
configuration allowing for it is enabled
Thanks, Sergey
On 05/07/17 18:17, William Denniss wrote:
Earlier this week I submitted the following I-D:
https://tools.ietf.org/html/draft-wdenniss-oauth-incremental-auth
The topic is incremental authentication (or incremental auth for
short). Incremental auth is used to enable clients to request just the
scopes they need when they need them – rather than all upfront – while
still only a maintaining a single authorization grant.
The I-D details two techniques used at Google, one that has been used
for a while in confidential clients, and one that we launched recently
as a new solution to deliver incremental auth for public clients.
I look forward to discussing this proposal with the working group. I
plan to present this draft at IETF99, hope you can be there or watching
the livestream!
I plan to ask for a call for adoption after that presentation. If you're
interested in this topic I'd encourage you to read the draft (it's
fairly concise!).
Best,
William
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
