Le 25 oct. 2013 19:28, "Torsten Lodderstedt" <tors...@lodderstedt.net> a écrit : > > > Am 25.10.2013 11:19, schrieb Thomas Broyer: >> >> >> >> >> 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 > > > 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/> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
