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

[Thomas Broyer <[e-mail]>]

Le 25 oct. 2013 19:28, "Torsten Lodderstedt" <[e-mail]> a
écrit :
>
>
> Am 25.10.2013 11:19, schrieb Thomas Broyer:
>>
>>
>>
>>
>> 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
>
>
> I assume you mean signing the request or at least some request data. Just
signing the access token won't help.

I meant signing the access token + PR identifier/URI + some timestamp, at a
minimum.
I explained it better in my answer to Justin; something like jwt-bearer
applied to access tokens.

>> 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/>
>
>