<div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>Thanks Justin for the explanation. I just ran into the same issue and I could not figure what was wrong...<br></div>However, I'm probably missing something.<br></div>How a resource server is supposed to check the access token and get the scope?<br></div>In order for my RS to query the introspection endpoint, I create a specific client.<br></div>Therefore, I have the client A, a single page app for instance, and a client B, the resource server.<br></div>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.<br><br></div>What do you think?<br><br></div>Yannick<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 12:48 PM, Justin Richer <span dir="ltr"><<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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".<br>
<br>
I would not recommend removing the check entirely, <i>however</i>:
the behavior has changed in version <b>1.2.0</b> 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.<br>
<br>
-- Justin<div><div class="h5"><br>
<br>
<div>On 8/27/2015 4:12 AM, Zaninetta Stefano
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt">Hello,<br>
<br>
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.<br>
(<a href="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" target="_blank">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</a>)<br>
<br>
I don't understand what is the reason of for that check and I
couldn't find such recommendation in the latest specs
(<a href="https://tools.ietf.org/html/draft-ietf-oauth-introspection-11" target="_blank">https://tools.ietf.org/html/draft-ietf-oauth-introspection-11</a>).<br>
Could anyone explain me what is the rationale behind that?<br>
<br>
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.<br>
Hence, I was considering removing it from the code, but I want
to be sure I'm not missing any security implication.<br>
<br>
Thanks a lot,<br>
Stefano<br>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><pre>_______________________________________________
mitreid-connect mailing list
<a href="mailto:mitreid-connect@mit.edu" target="_blank">mitreid-connect@mit.edu</a>
<a href="http://mailman.mit.edu/mailman/listinfo/mitreid-connect" target="_blank">http://mailman.mit.edu/mailman/listinfo/mitreid-connect</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
mitreid-connect mailing list<br>
<a href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a><br>
<a href="http://mailman.mit.edu/mailman/listinfo/mitreid-connect" rel="noreferrer" target="_blank">http://mailman.mit.edu/mailman/listinfo/mitreid-connect</a><br>
<br></blockquote></div><br></div>