auto-approving in oAuth2

[Steven Livingstone Pérez]

Under what circumstances may you auto-approve an oAuth2 request - when is it "safe" to do so (or rather when should you avoid doing so)?

Are there cases where you would auto-approve a client alone *without* a user identity? I assume that the client would first have to have authenticate and subsequently any requests could then be auto-approved. I've not used a case where this happens with just the client but maybe in some public api scenario?

The typical use case i'd imagine is where you do authenticate a user via for a given client request and subsequent requests can then be auto-approved to give new access tokens over the lifetime of the app?

Is this close to being correct? The idea being you only want to ask them to approve the first time (but at least once) and any further redirects for approval to get a new access token (when not using the refresh token) can be auto-approved (unless i'd assume the client approval was somehow revoked)?

Hope that terminology is close to being correct :-)

cheers,

steven

[Werner Strydom]

Hi Steven,

I generally auto approve non-interactive service applications that access the API where user approval is impossible. For example, an internal windows service that connects to an internal or public API to perform some work.  Another may be a console application that interacts with the API that is triggered by a task scheduler. The bottom line is that user approval may be impossible, inconvenient or impractical. 

There are two categories I would consider.

The first being internal trusted service applications that require access to all the data of all the users. These are typically internal systems that are explicitly trusted to perform some critical work.  If the client identifier and secret is compromised for this type of application, your system as a whole can be compromised.  Frequently rotating the client identifier and client secret may mitigate the risk as well as limiting which addresses the service calls can be made of.  

The second being untrusted service applications specific to users (or the organizations they belong to). The user trusts the application implicitly because they wrote it, but our system does not. Here care must be taken that such applications can only access data of the user (or organization they belong to) and not of others.  I generally consider the client identifier and client secret as another set of credentials to identify the user who created the application.

In either case, the weakest point here is the client secret. So if you store it in your database in clear text and someone manages to gain access to your database everyone's data can easily be compromised, even if encrypted.  Essentially it suffers of the same problem as passwords and should be handled with the same security considerations.

Cheers,

Werner

[Andrew Arnott]

The most important rule in my mind is:

Never auto-approve a request that the user hasn't previously authorized (with a "remember this" checkbox perhaps).  

Werner's point about internal trusted applications is good though.  Certainly within the authorization server's own org there may be apps that reside on servers that you control and trust, and can keep a secret.  I don't consider this a violation of my above rule because the user already trusts the authorization server's company (that's why the user is storing data there) so if that company has internal need to spread data around, that's all part of that.

The "inconvenient, impractical, etc." reasons for not asking approval from the user are no reasons at all in my strong opinion.  Inconvenience is a very poor reason for giving away user data without their consent.  

The OAuthAuthorizationServer's OAuthController has a rudimentary auto-approve check.  Basically if the client is asking for authorization that is a subset (w.r.t. scope) of what has previously been granted by the resource owner to that client then there is no reason to ask the user to confirm that again, so the user step is skipped.  

One massive caution: auto-approval of implicit grants is very dangerous, and in my opinion should never be done.  This gives any installed client app access to that user's data on the resource server without user approval or knowledge.  This is because the implicit grant requires no client secret, so any client can impersonate any other client.  For installed clients this is trivial to execute the attack.  For JS clients, there are mitigations such as pre-registered callback URLs but even then I bet almost all JS clients are still vulnerable.  Most client callback URLs probably sniff the access token from the fragment, and pass it back to the parent page.  So in fact (AFAIK) there is (usually?) nothing preventing an attacker from hosting a hidden iframe with an auth request that impersonates a popular client, which gets auto-approved, and then accepts the access token when the real client's own callback page ignorantly hands the access token off to the wrong client.  I believe mitigations exist (checking parent.location before sending the parent the token may work here), but I wonder how often they are employed.

If you want your JS clients to avoid having to prompt the user again every time the access token expires, I recommend using the authorization code grant and issue refresh tokens to non-authenticated clients, which recent drafts of the oauth 2 spec allow for (but DNOA does not yet, IIRC).

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/K3o-M_kAVvEJ.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Werner Strydom]

I fail to add that I always require a client secret when authorizing the client and don't permit implicit grants.

The context of auto approving clients because its "impossible, inconvenient or impractical" only relates to trusted clients.  The scope of trust is determined by who wrote it.  If its the vendor, the scope of trust extends to all data, and if it is the user, then the scope of trust is limited to their data alone.  As for any other type of client, authorization is explicitly required or authorization is denied.