[mitreid-connect] Introspection endpoint - scopes check

[Yannick Béot]

Thanks for your quick answer.
I'll try to upgrade to 1.2.0 ASAP to prevent 403 errors or the need to
synchronize scopes between the client and resource server.

Y.

On Thu, Sep 3, 2015 at 10:55 PM, Justin Richer <jricher at mit.edu> wrote:

> That is the correct setup — B is the resource server. We re-used the
> “client” system in MITREid because it already had all of the attributes
> that we cared about for resource servers and it didn’t make sense to
> duplicate it.
>
> The resource server checks the access token when the client presents the
> access token to the resource server. The resource server simply picks the
> token up off of the incoming request and sends it to the introspection
> endpoint, along with the resource server’s credentials. The response that
> comes back contains the scopes for the token, among other things. The
> resource server can then decide what it wants to do with that.
>
>  — Justin
>
> On Sep 3, 2015, at 4:30 PM, Yannick Béot <yannick.beot at gmail.com> wrote:
>
> 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/623cdfa6/attachment.html