Am 25.10.2013 11:19, schrieb Thomas Broyer:
On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt
<tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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.
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/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
