Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth and
Justin's token introspection draft. Token introspection on its own is a
"shallow" kind of loose coupling between authorization servers and resource
servers. If these are operated by different organizations, as appears to be the
case for you, then "deep" loose coupling may be need to answer questions about
how the AS and RS onboard and establish trust with each other. UMA provides one
set of answers for how to do this. You can find more info at
http://tinyurl.com/umawg.
Eve
On 22 Oct 2013, at 7:50 AM, Thomas Broyer <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/
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
Eve Maler http://www.xmlgrrl.com/blog
+1 425 345 6756 http://www.twitter.com/xmlgrrl
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
