Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

[Torsten Lodderstedt <[e-mail]>]

Hi Daniel,

> Am 09.11.2019 um 18:44 schrieb Daniel Roesler <daniel=[e-mail]>:
> 
> I realize that it's open to the authorization server to issue
> authorization codes how they see fit. It just strikes me as odd that
> there's not a lot of guidance around when transparent redirects are
> safe, when user interaction should occur, and the risks and
> implications of both behaviors.

User consent is more difficult than it looks on first sight. That’s the reason why it is hard to come up with general guidance.

To start with, user consent is not a security measure per se. It is a measure to establish the legal basis for access to services and data on behalf of the resource owner. It is important to gather the consent but also to enforce this consent (typically by the RS) and ensure that only the legit client is able to use the tokens issued based on a certain consent (scope). That’s were various security pieces come into play.

If AS and client belong to the same legal entity, there is typically no need to gather consent since the user already consented to the terms and privacy policy of the respective service provider. So automatic code issuance is fine as long as the user is sufficiently authenticated (policy determine by RS).

If AS and client belong to different legal entities, the AS can ask every time - that’s on the super safe side but inconvenient. That’s why ASs may store the consent and avoid another dialog, if the same client asks again for the same scope.

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.

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.

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) The client identification problem will most likely stay.

kind regards,
Torsten.