[mitreid-connect] Introspection endpoint - scopes check
Justin Richer
jricher at mit.edu
Thu Aug 27 06:48:21 EDT 2015
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 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/20150827/45a14cd4/attachment-0001.html
More information about the mitreid-connect
mailing list