On Nov 9, 2019, at 1:08 PM, Torsten Lodderstedt <tors...@lodderstedt.net> wrote:
> But what does „same client“ mean? Is it the client_id? Sounds reasonable for
> a web app, but would also mean instances of the same native app residing on
> different devices could share the consent. That’s great from a convenience
> perspective but the AS has to really make sure it’s the same user on the
> other device using the 3rd party app and it’s the same app again otherwise an
> attacker could easily abuse the grant.
>
> This in turn would call for client authentication, which in this case (same
> client_id shared among instances) means the OAuth dialog must happen in a
> backend otherwise the secret could be obtained by an attacker from the
> installed app.
<pipes back in>
Very true, and this is one reason why in Native Apps and Web Apps deployments
(which use public clients) the AS may use the ability to redirect to a unique
redirect URI as a form of lightweight identifier/ownership proof. That means
some forms of redirect URI where you cannot provide unique ownership (custom
schemes on most platforms, localhost redirects) should understand that other
software can imitate the given client to the user, and that as a result allowed
authorizations might be reduced and SSO/consent should be more carefully
managed.
> I hear “dynamic client registration” to give every instance client_id and
> secret? Well, looks like an alternative, but one needs to establish the
> relationship to the legal entity in a secure manner, otherwise sharing the
> consent is dangerous. Software statements or registration access tokens are
> the means at hand but both are shared secrets one would need to deploy with
> all app instances ... not advisable at all.
As DCR gives you the means to uniquely identify a client, I would expect each
instance to be represented as a separate client. That brings you up from
‘consent on every token request by every client instance’ to ‘consent once for
each client instance’. You could still use something like unique redirect URI
or platform attestation to make it 'consent once per client’.
DCR does give you another handle for tracking a client instance across
authorization requests, which can be otherwise difficult in the scenario public
clients relying on a browser user agent. A native app may be able to persist
that better than say what you get via browser storage.
> Let’s talk about “same scope”: equality can be defined as byte level string
> equality or by interpreting the scope. The first approach will cause another
> user consent dialog if the order of the scope values change (or just a space
> is added). The latter approach is highly implementation specific since left
> undefined in RFC 6749.
>
> In the case of Open Banking and similar scenarios, this scope will be fine
> grained, dynamic or even transactional meaning storing a consent and issuing
> another code in subsequent authorization transactions might be possible but
> scope value specific.
>
> Constraints regarding the duration of a consent can easily be enforced by the
> AS. It just won’t issue further codes or access tokens (in case of refresh
> token grant) if the consent needs to be refreshed.
>
> bottom line: to define when an AS can issue an authorization code without
> asking for user consent again is easy. Implementing a policy that is secure
> and convenient is not.
>
> We are working on more sophisticated ways to represent and compare scopes
> (https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03
> <https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03>). The client
> identification problem will most likely stay.
One of the benefits of the OAuth abstraction is that it puts the authorization
business logic (including things like presentation) squarely in the hands of
the AS. OAuth gives the flexibility for the AS to implement that logic
appropriately, as well as to evolve that logic without impacting the protocol
contract with the clients/protected resources.
That there even is consent is part of that business requirements on an
organization, so it would be difficult to give formal recommendations outside
of business needs (e.g. regulatory compliance). Outside that, recommendations
would be non-prescriptive considerations for AS implementors, such as “limit
the scopes available to a client based on client need, client audit, business
relationship, and regulatory restrictions/requirements”
There are also cases where general user interaction (e.g. non-transparent
SSO/authorization) is technically desirable, such as fortifying the AS from
being classified as a tracker in Safari ITP or ensuring Universal Links will
work on iOS. If you are requiring the user click to continue as a technical
solution, you might decide to use that as an opportunity for information or
informed consent as well.
-DW
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
