This was discussed extensively and is covered in the text of the RFC, but the
summary is simple: the request isn’t a bad request (which is what 400 means).
It’s a perfectly valid request, it’s just that the token you’re asking about
might not be valid for some reason, or it might not be valid *for you*. Either
way, you don’t actually want to divulge too much information about why the
token is bad in a production environment or else you let attackers poke around
and learn more about the system than they really need to know to function. As
far as a protected resource is concerned, it likely doesn’t matter anyway. And
an OAuth client isn’t going to be propagated that information, it’s just going
to have to go get a new token. Since an OAuth client needs to be able to get a
new token at a moment’s notice anyway, there’s not really anything useful in
communicating it.
This is a similar approach to the Revocation spec (RFC 7009) which always
returns 200 whether or not the token existed or was successfully revoked. In
any event, the client needs to assume that the token was revoked and stop using
it, and it’s up to the server to deal with the consequences of error
conditions.
Hope this helps,
— Justin
> On Oct 21, 2015, at 4:27 PM, Vivek Biswas <vivek_bis...@yahoo.com> wrote:
>
> Yes indeed a nice job !!!!.
>
> I have one question on the RFC.
>
> Not sure where I can submit request for comments. Hence, adding to this email
> thread
>
>
> In the use-case mentioned below
> The following is a non-normative example response for a token that
> has been revoked or is otherwise invalid:
>
> HTTP/1.1 200 OK
> Content-Type: application/json
>
> {
> "active": false
> }
>
>
>
> Where the token is revoked or invalid, why not send a HTTP response code of
> 400
>
> There are 2 benefits for the same.
> A. Just looking at the header, we know that token validation didn't went
> through. No need to look in the payload. This is especially very helpful in
> gateway design implementation.
>
> B. You are further hiding from the user why the request failed and not
> letting him know if the token was processed by the server.
>
> Cheers
> Vivek
>
>
>
> From: Kathleen Moriarty <kathleen.moriarty.i...@gmail.com>
> To: Hannes Tschofenig <hannes.tschofe...@gmx.net>
> Cc: "<oauth@ietf.org>" <oauth@ietf.org>
> Sent: Wednesday, October 21, 2015 4:47 AM
> Subject: Re: [OAUTH-WG] RFC 7662 on OAuth 2.0 Token Introspection
>
> Yes, nice job!
>
> Sent from my iPhone
>
> > On Oct 21, 2015, at 4:20 AM, Hannes Tschofenig <hannes.tschofe...@gmx.net
> > <mailto:hannes.tschofe...@gmx.net>> wrote:
> >
> > Thank you Justin for the hard work!
> >
> >> On 10/20/2015 06:32 PM, Justin Richer wrote:
> >> Thank you to everyone who helped make token introspection into a real
> >> standard!
> >>
> >> — Justin
> >>
> >>> On Oct 19, 2015, at 6:56 PM, rfc-edi...@rfc-editor.org
> >>> <mailto:rfc-edi...@rfc-editor.org> wrote:
> >>>
> >>> A new Request for Comments is now available in online RFC libraries.
> >>>
> >>>
> >>> RFC 7662
> >>>
> >>> Title: OAuth 2.0 Token Introspection
> >>> Author: J. Richer, Ed.
> >>> Status: Standards Track
> >>> Stream: IETF
> >>> Date: October 2015
> >>> Mailbox: i...@justin.richer.org <mailto:i...@justin.richer.org>
> >>> Pages: 17
> >>> Characters: 36591
> >>> Updates/Obsoletes/SeeAlso: None
> >>>
> >>> I-D Tag: draft-ietf-oauth-introspection-11.txt
> >>>
> >>> URL: https://www.rfc-editor.org/info/rfc7662
> >>> <https://www.rfc-editor.org/info/rfc7662>
> >>>
> >>> DOI: http://dx.doi.org/10.17487/RFC7662
> >>> <http://dx.doi.org/10.17487/RFC7662>
> >>>
> >>> This specification defines a method for a protected resource to query
> >>> an OAuth 2.0 authorization server to determine the active state of an
> >>> OAuth 2.0 token and to determine meta-information about this token.
> >>> OAuth 2.0 deployments can use this method to convey information about
> >>> the authorization context of the token from the authorization server
> >>> to the protected resource.
> >>>
> >>> This document is a product of the Web Authorization Protocol Working
> >>> Group of the IETF.
> >>>
> >>> This is now a Proposed Standard.
> >>>
> >>> STANDARDS TRACK: This document specifies an Internet Standards Track
> >>> protocol for the Internet community, and requests discussion and
> >>> suggestions
> >>> for improvements. Please refer to the current edition of the Official
> >>> Internet Protocol Standards (https://www.rfc-editor.org/standards
> >>> <https://www.rfc-editor.org/standards>) for the
> >>> standardization state and status of this protocol. Distribution of this
> >>> memo is unlimited.
> >>>
> >>> This announcement is sent to the IETF-Announce and rfc-dist lists.
> >>> To subscribe or unsubscribe, see
> >>> https://www.ietf.org/mailman/listinfo/ietf-announce
> >>> <https://www.ietf.org/mailman/listinfo/ietf-announce>
> >>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> >>> <https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist>
> >>>
> >>> For searching the RFC series, see https://www.rfc-editor.org/search
> >>> <https://www.rfc-editor.org/search>
> >>> For downloading RFCs, see https://www.rfc-editor.org/rfc.html
> >>> <https://www.rfc-editor.org/rfc.html>
> >>>
> >>> Requests for special distribution should be addressed to either the
> >>> author of the RFC in question, or to rfc-edi...@rfc-editor.org.
> >>> <mailto:rfc-edi...@rfc-editor.org.> Unless
> >>> specifically noted otherwise on the RFC itself, all RFCs are for
> >>> unlimited distribution.
> >>>
> >>>
> >>> The RFC Editor Team
> >>> Association Management Solutions, LLC
> >>>
> >>>
> >>> _______________________________________________
> >>> OAuth mailing list
> >>> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >>> https://www.ietf.org/mailman/listinfo/oauth
> >>> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> <https://www.ietf.org/mailman/listinfo/oauth>
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> > <https://www.ietf.org/mailman/listinfo/oauth>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> 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
