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. 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). regards, Torsten. Thomas Broyer <t.bro...@gmail.com> schrieb: >On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. ><jric...@mitre.org>wrote: > >> Hi Thomas, >> >> You're right in that the introspection process is about getting meta >> data about a particular token by making an authenticated call. It >does >> reveal a lot of information about the token -- because that's exactly >the >> point of the protocol. :) >> >> If the PR is compromised, then the attacker would be able to do >anything >> the PR can do, including reusing any tokens handed to the PR >(assuming >> they're bearer tokens). >> > >Yes, this is the problem with bearer tokens. Is there any spec for >'proof >tokens' besides http-mac? >As a mean of mitigating the issue, I was thinking about delivering a >refresh_token and asking Clients to generate (ask the AS) different >access >tokens for each PR (or "resource set"). That would of course solve the >issue with introspection giving too much information (to my taste), but >puts burden on Client implementors, with no guarantee that they'll >actually >do it. AFAICT, only a 'proof token' would really solve the issue; it's >in >our backlog. > > >> This is true without doing introspection at all, since you can just >steal >> and start broadcasting the token. >> > >But then the AS could revoke the access token when it detects a high >rate >of validation/introspection requests from many different PRs, >particularly >many such requests in error! >Giving the compromised victim the list of scopes for the token would >severely limits the number of errors and it would be much harder to >detect >such compromised entities. > >Also, if the PR is compromised, all the data protected at that PR is >also >> compromised, so you've got other problems too. >> > >That's a problem between the PR and the ROs then, unrelated to the AS >or >even Clients. >It becomes a problem with the whole system when compromising one entity >(other than the AS) gives access to personal data in others. > > >> The "resource_id" parameter is meant to be a service-specific hint >that >> the PR can hand to the AS to give context to the transaction. You >could >> easily use this field to pass along the list of scopes that you >mention >> below. >> > >I had just skimmed through resource-reg and didn't remember the >"resource >set" concept. Now that I re-read it, I better understand what that >resource_id can be. > > >> You can have your AS return no information other than the "valid" >field in >> the response and leave out the scopes, subject, client id, and >everything >> else. All those fields are optional. However, in practice we've found >it >> very helpful to reveal to the PR which scopes and audiences that a >token >> was issued for so that the PR can use that information to make >> authorization decisions. >> > >But aren't authorization decisions the responsibility of the AS? >If the PR sent the scopes (or resource_id, but that would closely >couple >the protocol with resource-reg, which I don't think is desirable) to >the >AS, then the PR could authorize access based only on a yes/no response >(and >the "no" response would give information about the "why", to be sent >directly to the Client) > > >> But if all you're after is answering the question "is this token >valid" >> and you don't want any other information, your AS is fully allowed to >do >> answer just that question. >> > >As I said, I do need "more information", or rather, a more "contextual" >information. > >I think I'll just go with my custom protocol for now. Thanks for your >answer. > > >------------------------------------------------------------------------ > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
