These specs cover two different connections: 6750 is client to RS, 7662
is RS to AS.
When the authorization server and the resource server are the same box,
it will know exactly why the token isn't any good and it can react
accordingly. The client doesn't actually care: note that the error
response in the example is descriptive text and not a value to be parsed
and acted upon.
In the case where they're a separate box (which is what introspection is
set up for), the RS might not be allowed to know the details about the
token not being good, and in any event it doesn't change how the RS
responds to that situation.
So to use them together, you would respond with "active: false" from
introspection and return a WWW-Authenticate header with "invalid_token"
from the resource to the client, no description field needed.
-- Justin
On 2/13/2017 4:59 PM, Maduranga Siriwardena wrote:
Hi All,
While going through [1] and [2] I noticed a small contradiction
between the standards.
Section 3 (The WWW-Authenticate Response Header Field) of [1] provides
a example with WWW-Authenticate header description error description
with "The access token expired".
This error description should have been obtained from the response of
introspection request sent to the authorization server. But according
the section 2.2 (Introspection Response) of [2], it is not recommended
to include any additional information about an inactive token,
including why the token is inactive.
So how these scenarios match with each other?
[1] https://tools.ietf.org/html/rfc6750
<https://tools.ietf.org/html/rfc6750>
[2] https://tools.ietf.org/html/rfc7662
<https://tools.ietf.org/html/rfc7662>
Thanks,
--
Maduranga Siriwardena
Software Engineer
WSO2 Inc.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
