On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt < 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 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
