Just use the token at your target API and see if it works. Your client’s going 
to need to be able to get a new token if this one expires mid-session anyway, 
so you’re not saving anything by doing an introspection request.

 — Justin

> On Jul 20, 2015, at 9:34 PM, Aaron Parecki <aa...@parecki.com> wrote:
> 
> I'm looking for a way to check if an existing token is still valid. Imagine a 
> client is holding on to a token between user sessions, for example if it's 
> making API requests for the user on a cron job. When the user returns to the 
> site, I want to check if the token is still valid, and make them sign in 
> again if not. 
> 
> Aaron
> 
> On Mon, Jul 20, 2015 at 12:11 PM John Bradley <ve7...@ve7jtb.com 
> <mailto:ve7...@ve7jtb.com>> wrote:
> If you want the resource owner/user then get a id_token from the token 
> endpoint.  That saves another call to a introspection endpoint.   
> 
> Sent from my iPhone
> 
> On Jul 20, 2015, at 7:49 PM, Aaron Parecki <aa...@parecki.com 
> <mailto:aa...@parecki.com>> wrote:
> 
>> Okay, if the intent is for this endpoint to be used by the resource server, 
>> this all makes sense. I was under the impression that it could also be used 
>> by clients to verify if the token is valid. Is there some other spec I could 
>> look at that is intended to be used by clients to verify if a token is valid 
>> and find out the user ID associated with it?
>> 
>> ----
>> Aaron Parecki
>> aaronparecki.com <http://aaronparecki.com/>
>> @aaronpk <http://twitter.com/aaronpk>
>> 
>> 
>> On Sun, Jul 19, 2015 at 10:01 PM, Justin Richer <jric...@mit.edu 
>> <mailto:jric...@mit.edu>> wrote:
>> Because the target isn’t the client, it’s the protected resource. We’re 
>> re-using OAuth’s client credentialing mechanisms (optionally, you can use 
>> whatever you deem necessary), but it’s not a client that’s doing it. That’s 
>> why it was changed to a MUST — there may be public clients out there (which 
>> could also use RFC7591 to become non-public), but public resource servers 
>> don’t make nearly as much sense.
>> 
>> Additionally, the discussion for this was back in December during the WGLC, 
>> and the time for normative changes to this particular spec is largely over 
>> at this stage.
>> 
>>  — Justin
>> 
>>> On Jul 20, 2015, at 12:03 AM, William Denniss <wdenn...@google.com 
>>> <mailto:wdenn...@google.com>> wrote:
>>> 
>>> I see in earlier drafts that client authentication MUST was a SHOULD.
>>> 
>>> Why not put it back to a SHOULD, and make these arguments in the Security 
>>> Considerations?  By the sound of it in some implementations there are good 
>>> reasons for doing client authentication, but they may not apply to 
>>> everyone, so do we need to be so prescriptive?  An error response can be 
>>> added for requests the server deems require client authentication.
>>> 
>>> It wouldn't have to be an all-or-nothing policy choice either, a server 
>>> could chose to reject requests from confidential clients where client 
>>> authentication is not provided, but accept requests without client 
>>> authentication from non-confidential clients.  A server that has 
>>> sufficiently high entropy in the tokens, abuse protection on the endpoint, 
>>> and is not concerned about an unrelated party (that happens to have a token 
>>> intended for a different party) learning the token metadata, could simply 
>>> not require any client authentication at all.
>>> 
>>> Apart from anything, it is really trivial to support non-confidential 
>>> client usage, so why not?  Perhaps there are some use-cases that will turn 
>>> up in the future (especially since as defined the introspection response is 
>>> extensible). One I can think of now is debugging: it's useful during 
>>> development to be able to inspect the tokens you get back from the AS.
>>> 
>>> Best,
>>> William
>>> 
>>> 
>>> On Sun, Jul 19, 2015 at 9:14 PM, Justin Richer <jric...@mit.edu 
>>> <mailto:jric...@mit.edu>> wrote:
>>> In the case of a “public client” using a token, the authorization is the 
>>> token that the resource server uses to call the introspection endpoint, 
>>> along side the token that it is introspecting. This is exactly how the UMA 
>>> protocol works: the resource server has a “Protection API Token” that it 
>>> uses to call several endpoints at the AS, including the introspection 
>>> endpoint. In UMA, this PAT is given to the resource server through a normal 
>>> OAuth transaction with an end user who facilitates the RS->AS introduction.
>>> 
>>> And I think this is all actually a moot point because clients shouldn’t be 
>>> doing the introspection in the first place — the whole spec is there to 
>>> support resource servers introspecting at the auth server. So you probably 
>>> don’t have “public client resource servers” out there. We simply re-used 
>>> OAuth’s existing client authentication mechanism, that doesn’t make them 
>>> clients. This decision is based on development and deployment experience 
>>> (as in, several people independently built it exactly this way). Do you 
>>> have a use case where you’ve got a protected resource that can’t hold 
>>> credentials (either a client secret or a public/private keypair) to 
>>> authenticate with, and can’t be introduced using OAuth to the AS as in UMA?
>>> 
>>> To your other point: An attacker has less of a chance of getting 
>>> information about a token by fishing at a protected resource with tokens, 
>>> since they’re not being returned information about the token other than the 
>>> fact that the token worked. (Or at least it seemed to work because a result 
>>> came back — you could easily give a suspected attacker 
>>> valid-looking-but-fake data as one mitigation mechanism.) The introspection 
>>> response can give you information about where else the token could be used, 
>>> potentially. Additionally, the RS really ought to be preventing 
>>> data-fishing attacks like this just for its own sake anyway. There are lots 
>>> of techniques for doing this, but they tend to be specific to the kind of 
>>> API that’s being served.
>>> 
>>> Requiring the resource server to authenticate with the authorization server 
>>> also allows you to do a few other useful things. Our implementation, for 
>>> example, limits the token information that is returned to a particular AS. 
>>> This allows us to have tokens that can be used in multiple RS’s without 
>>> those RS’s ever even knowing the token is powerful enough to be used 
>>> elsewhere. It prevents information about the authorization from leaking to 
>>> parties who have no business knowing.
>>> 
>>> Hope this helps clarify it,
>>>  — Justin
>>> 
>>>> On Jul 19, 2015, at 7:59 PM, Aaron Parecki <aa...@parecki.com 
>>>> <mailto:aa...@parecki.com>> wrote:
>>>> 
>>>> How are public clients supposed to authenticate if there is no secret?
>>>> 
>>>> Isn't "fishing for valid tokens" just as much of an issue at the resource 
>>>> server? I don't see how having the introspection endpoint require client 
>>>> authentication actually solves the fishing problem since attackers could 
>>>> just fish against the resource server. In fact, if the resource server 
>>>> queries the introspection endpoint to check if tokens are valid, then that 
>>>> effectively gives an attacker a way to fish for tokens using the resource 
>>>> server's credentials. 
>>>> 
>>>> ---
>>>> Aaron Parecki
>>>> http://aaronparecki.com <http://aaronparecki.com/>
>>>> 
>>>> On Sat, Jul 18, 2015 at 10:04 PM Justin Richer <jric...@mit.edu 
>>>> <mailto:jric...@mit.edu>> wrote:
>>>> Public clients can use the token-based auth mechanism, can’t they? If you 
>>>> don’t have some form of authentication on the introspection endpoint, you 
>>>> end up with a way for people to anonymously and programmatically fish for 
>>>> valid token values. 
>>>> 
>>>>  — Justin
>>>> 
>>>> 
>>>>> On Jul 19, 2015, at 6:30 AM, Aaron Parecki <aa...@parecki.com 
>>>>> <mailto:aa...@parecki.com>> wrote:
>>>>> 
>>>> 
>>>>> The introspection draft states that the introspection endpoint MUST 
>>>>> require authentication of clients. It mentions either client 
>>>>> authentication (id+secret) or a separate bearer token.
>>>>> 
>>>>> How are public clients expected to use the token introspection endpoint? 
>>>>> I didn't see a note in the document about that at all.
>>>>> 
>>>> 
>>>>> ----
>>>>> Aaron Parecki
>>>>> aaronparecki.com <http://aaronparecki.com/>
>>>>> @aaronpk <http://twitter.com/aaronpk>
>>>>> 
>>>>> _______________________________________________
>>>>> 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

Reply via email to