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). This is true without doing introspection at all, since you can just 
steal and start broadcasting the token. Also, if the PR is compromised, all the 
data protected at that PR is also compromised, so you've got other problems too.

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. 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 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 Eve pointed out in the other email, the introspection draft allows for a 
light "loose" binding between the AS and PR, but there's an assumption that the 
relationship was set up somewhere. UMA adds the possibilities of a deeper and 
more dynamic binding between PR and AS before introspection takes place. (In 
fact, the introspection draft was pretty much lifted out of UMA originally.) 
UMA also has a concept of permission sets that are more flexible and 
descriptive than scopes alone are, but those are added to the top of the base 
introspection response.

 -- Justin


On Oct 22, 2013, at 7:50 AM, Thomas Broyer 
<t.bro...@gmail.com<mailto:t.bro...@gmail.com>> wrote:

Hi all,

In a platform we're building, we have AS, clients and PRs all as distinct 
parties managed/provided by distinct companies. There's a single AS though, 
doing SSO through OpenID Connect (i.e. the AS in an OP).

I thus need a way for a PR to ask the AS whether the token presented by the 
client is valid and grants access to the PR. I've thus briefly evaluated 
draft-richer-oauth-introspection-04 which seemed to fulfill my needs. Here are 
my comments:

First, I'm a bit disturbed about privacy and potential security issues about 
the way this is done (disclaimer: I'm in no way a security expert). This draft 
is really about "introspection", and not "validation" of a token, and that 
might be the problem: it returns the information about a token to whoever asks 
for it (provided it authenticates, and possibly only if the token grants it 
access, but that would mean there's an association in the AS between scopes and 
registered PRs, themselves identified by a client_id); this is IMO disclosing 
too much information.
In case the PR is compromised, this information could be used to then reuse the 
token with other PRs inferred by the token's granted scopes and gain access to 
private information in a way that the End User didn't explicitly approved (he 
authorized the Client to access several PRs, he didn't authorize exchanges 
between PRs directly). This could be mitigated by *not* using Bearer tokens 
(using some sort of 'proof token' instead, e.g. either MAC or JWT), but there's 
no reason we couldn't have such a feature/endpoint that could work securely 
with Bearer tokens (I don't want to put too much burden on client and PR 
implementers).
Before I saw this draft, my idea was to have an endpoint at the AS where the PR 
would send the token received by the Client *and* the scopes corresponding to 
the request being done (and the "sub" of the End-User if it was part of the 
request; in our case, we use it as a global identifier shared by all parties 
involved; we might change to per-party IDs and then use that endpoint to 
"translate" the ID as known by the Client to the ID as known by the PR, but 
this is another story), and the AS would answer with just a "yes" (HTTP/1.1 204 
No Content) or "no" (400 Bad Request with a JSON payload similar to the Error 
Response from Section 5.2 or RFC 6749, with the same error codes as defined by 
RFC 6750; that way the PR can just "translate" the error response to a 
WWW-Authenticate: Bearer response header). That way, the PR does not know where 
else the token is "valid", i.e. what it could do with it.

Second thing, the draft talks about a "resource_id" but doesn't say how it 
could be used, and whether it'll be used at all by the server, what impact it 
could have on the response, etc. Could that resource_id replace the "list of 
scopes" from my implementation idea? The PR would need to know the list of 
scopes to return the correct WWW-Authenticate header anyway (assuming a Bearer 
token is used here), so I'm not sure it's really better. And the resource_id is 
optional, so what would happen if it's not provided? you'd have *more* 
information returned? I understand that this is just a framework and each 
server would have its own rules, but you're then either saying too much or too 
few.

Thanks in advance for any guidance about how to achieve my goal. Should I go 
with introspection? (maybe I misunderstood something, or saw a threats where 
there isn't) or should I use something else? Does my initial idea make sense? 
Should I go with it?

--
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

Reply via email to