[mitreid-connect] Introspection endpoint - scopes check

[Yannick Béot]

Hi,

Thanks Justin for the explanation. I just ran into the same issue and I
could not figure what was wrong...
However, I'm probably missing something.
How a resource server is supposed to check the access token and get the
scope?
In order for my RS to query the introspection endpoint, I create a specific
client.
Therefore, I have the client A, a single page app for instance, and a
client B, the resource server.
My single page app is requesting an access token to MITREid and send it to
B in REST query. B is using its own credential to query the introspection
endpoint and validate the access token.

What do you think?

Yannick

On Thu, Aug 27, 2015 at 12:48 PM, Justin Richer <jricher at mit.edu> wrote:

> The rationale behind this functionality is that you don't want to
> inadvertently leak information to a protected resource about the overall
> reach of a token if the token is usable beyond that particular protected
> resource. Let's say I have two resources, "A" and "B", and they have
> associated scopes, "a" and "b". If the client gets a token with scope "a b"
> and plays it at "A", we might not want "A" to inadvertently discover that
> the token could also be used at "B".
>
> I would not recommend removing the check entirely, *however*: the
> behavior has changed in version *1.2.0* such that the server doesn't
> return an error anymore, but instead returns only the scopes associated
> with the protected resource. In the scenario above, when "A" introspects
> the token with "a b", it gets back a response that only includes "a" in the
> scope field, while "B" would get back a response that only includes "b" in
> the scope field of the same token.
>
>  -- Justin
>
>
> On 8/27/2015 4:12 AM, Zaninetta Stefano wrote:
>
> Hello,
>
> I noticed that the Introspection endpoint is returning 403 if the
> introspecting client configuration doesn't include all the scopes
> associated with the introspected token.
> (
> https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/mitreid-connect-1.1.15/openid-connect-server/src/main/java/org/mitre/oauth2/web/IntrospectionEndpoint.java#L130
> )
>
> I don't understand what is the reason of for that check and I couldn't
> find such recommendation in the latest specs (
> https://tools.ietf.org/html/draft-ietf-oauth-introspection-11).
> Could anyone explain me what is the rationale behind that?
>
> At the moment the workaround we adopted is to configure all the available
> scopes for all the clients used by the Protected Resources; that is
> equivalent to skip the check.
> Hence, I was considering removing it from the code, but I want to be sure
> I'm not missing any security implication.
>
> Thanks a lot,
> Stefano
>
>
> _______________________________________________
> mitreid-connect mailing listmitreid-connect at mit.eduhttp://mailman.mit.edu/mailman/listinfo/mitreid-connect
>
>
>
> _______________________________________________
> mitreid-connect mailing list
> mitreid-connect at mit.edu
> http://mailman.mit.edu/mailman/listinfo/mitreid-connect
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.mit.edu/pipermail/mitreid-connect/attachments/20150903/20252426/attachment-0001.html