Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

[Thomas Broyer <[e-mail]>]

On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <
[e-mail]> wrote:

> Hi Thomas,
>
> we generate access tokens per resource server in order to mitigate this
> and other risks. You must issue those tokens to different audiences
> (resource server id) and the resource servers must validate if the token is
> issued for its particular audience. Otherwise a compromised resource server
> can still abuse the tokens.
>
> Talking about burden: You need to compare the effort needed to obtain
> different access tokens to the effort needed to implement proof of
> possession.
>

On our backlog is also support for "service accounts" (to use Google's
terminology), so clients will likely need to do some crypto-related work.
Asking them to do it for each and every request to sign the access token
might not be that much of a problem (if they have the right tools;
google-oauth-java-client for instance does a great job making all of this
easier, and google-api-java-client adds service accounts support with a
just-as-easy-to-use API:
https://code.google.com/p/google-api-java-client/wiki/OAuth2#Service_Accounts;
same for PHP, Python, etc.)
That said, I'm rather new to crypto too, so I might be oversimplifying
things…
I'll check with the project manager and project owner which approach we'd
use (we could also support both…)

I recommend you to take a look into the OAuth threat model for a discussion
> of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4).
>

Thanks for the pointer. I had already read that RFC but somehow forgot
about some details, and failed to check it back for that particular problem.


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>