Re: [OAUTH-WG] Comments on draft-richer-oauth-introspection-04

[Thomas Broyer <[e-mail]>]

On Thu, Oct 24, 2013 at 4:36 PM, Richer, Justin P. <[e-mail]>wrote:

>  On Oct 23, 2013, at 5:27 PM, Thomas Broyer <[e-mail]>
>  wrote:
>
>  On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. <[e-mail]>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.
>

Any pointer?
I've only see http-mac, but I'm surprised to find nothing similar to
jwt-bearer (i.e. a signed JWT whose claim set includes the access token;
the resource server could then send the JWT to the AS which would verify
the signature and validity of the JWT wrt "exp", "iat", "nbf" and "jti"
fields, and embedded access token –could be the "sub"?–; the JWT couldn't
be used with other resource servers as its "aud" field wouldn't match)
http-mac looks much more complex, and probably with very good reasons, but
my gut feeling is that if something like jwt-bearer, which looks simpler,
is deemed secure enough as grant-type or client-assertion-type, why would
it be different for accessing protected resources?
(disclaimer: remember, I'm not a security guy)


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

It's not yet really clear for us, but it'll probably be the case yes.


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

Ah yes, fair enough…
A resource_id would be a good abstraction then, as it would be "private",
only known to the resource server and authorization server, making it
harder to fish for other possible uses of the token.


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

Are you also returning different values for the "scope" based on which PR
makes the request? (filtering them to only include scopes the PR is tied to)
(I'm a web guy, and "profiling" the response depending on who accesses it
goes against my REST background and is not natural to me, but that would
work I guess)

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

Yes.

When using Token Introspection, that wouldn't be really needed though: a
400 response from the AS maps to an invalid_request, and {"active":false}
to an invalid_token, and the PR is in charge of determining whether to
return an insufficient_scope error.


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

By "more contextual", I meant that the "yes/no" response is more "precise"
than just "active/inactive": it's a yes/no for a particular request.
The only difference with Token Introspection is about disclosing the scopes
to the PR or not.

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

I'll try out Token Introspection and see if it can match. I actually
already know it will IFF I trade "wide scoped" bearer tokens to either "one
bearer token per resource server" (like Torsten said) or "proof tokens".


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>