On Oct 23, 2013, at 5:27 PM, Thomas Broyer <t.bro...@gmail.com<mailto:t.bro...@gmail.com>> wrote:
On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. <jric...@mitre.org<mailto: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. There are a couple of proposed holder-of-key type tokens proposed but none have been accepted by the working group yet. We'd be glad to have more input into it. 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. It depends on how closely the scopes map to specific resources and how much the attacker knows about that environment. It sounds like your usage of OAuth places a significant amount of information into the scope which would leak that information. In such an environment, having the PR supply the scope in the request somehow instead of the AS returning the scope in the response might help. However, what would prevent a compromised PR from fishing for the scopes of a given token, assuming they know the overall set of scopes the token could be good for? In our own implementation, the PR's are tied to a specific scope set and the AS knows which scopes a particular PR is meant to use. With this information, by local policy we can actually limit which tokens the PR is allowed to introspect. 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. Yes, and there are other means for mitigating these risks, as Torsten pointed out, and you'll really want to be doing these anyway in your system. 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. The resource_id isn't necessarily a resource set identifier, though it can be. It was really meant as a way for the PR to say "here's the context of the token being used". The other piece of context is the client identifier that's used as part of the client authenticating the call to the introspection endpoint. These, coupled with the token itself, can give a very complete view of the request.. 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? Partially, but it's the PR that makes the ultimate decision of whether or not to let the request proceed. The AS can only help provide information for the PR to make that final decision. 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) Again, I want to point out that resource_id isn't necessarily meant to be coupled with the resource registration protocol (though it can nicely overlap). An interesting idea to send back the reason why from the AS, I'm assuming this would be one of the error codes defined by RFC6750? You'd want to be careful about exposing too much information in the error though. 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. And you can add that contextual information, like UMA does, as part of the JSON structure that's returned. I think I'll just go with my custom protocol for now. Thanks for your answer. I would encourage you to rethink that stance, especially if the introspection protocol can be changed to accommodate your use case without breaking the existing use case that people are using it for. As it's a draft standard I'm fine with us tweaking things. Additionally, starting with introspection as it is would leave the door open to you interoperating with other systems in the future and even moving to a more comprehensive protocol like UMA. -- Justin
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
