Hi
On 07/07/17 18:56, William Denniss wrote:
What you describe is incremental auth.
Thanks... FYI, I thought of doing some work around it after browsing
through the Google docs; the line about the "asking to approve the
purchase of the kitchen sink at the authentication time is a death of
the modern web" (or something similar that I read on this list) was even
more convincing :-)
Aside: Do you return the "scope" in the token response as required when
the scope in the response is not identical to the request (§ 5.1
<https://tools.ietf.org/html/rfc6749#section-5.1>, parameter: scope)?
Yes, the token service is doing it by default for all the returned
access tokens
My only question is: does the client expect this? The spec talks about
the authorization server *reducing* scope in a few places (in § 3.3
<https://tools.ietf.org/html/rfc6749#section-3.3>, "The authorization
server MAY fully or partially ignore the scope requested by the client"
and § 10.3 <https://tools.ietf.org/html/rfc6749#section-10.3> "The
authorization server SHOULD take the client identity into account when
choosing how to honor the requested scope and MAY issue an access token
with less rights than requested."). It never talks about *increasing*
scope (other than it can't be done during refresh).
So I think some normative language around the potential to increase the
scope of the request for confidential clients (in either the way you
describe, or the way I described in the draft) is warranted.
Open question: should we require an indication from the client if they
*want* the scope increase? That's what include_granted_scopes was
designed to do. To allow clients to specify if this is behavior they desire.
Right, I see how a proposed "include_granted_scopes" can make it non
ambiguous
The more innovative part of the spec I think is the public (native app)
client incremental auth – as native apps cannot use the methods you
discuss, or the ones Google has supported for a while for confidential
clients. That said, if we write this – I think we may as well formally
document approaches for confidential clients too.
thanks, Sergey
On Fri, Jul 7, 2017 at 9:24 AM, Sergey Beryozkin <[email protected]
<mailto:[email protected]>> wrote:
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
<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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
