[mitreid-connect] Introspection -> active true for expired tokens?

[Justin Richer]

The expiration check ought to be happening inside the token service as so that an expired token is never returned. If that’s not happening, please file an issue.

 — Justin

> On Dec 7, 2015, at 5:42 PM, Luiz Omori <luiz.omori at duke.edu> wrote:
> 
> …and upon further investigations we found that there is a background task running every 5min (configurable value) that discards expired tokens. That in turn causes the Introspection to correctly return active=false. Shouldn’t the expired check be added to the Introspection endpoint to avoid that window where the token is already expired but Introspection is returning active=true?
> 
> Regards,
> Luiz
> 
> From: Luiz Omori <luiz.omori at dm.duke.edu <mailto:luiz.omori at dm.duke.edu>>
> Date: Monday, December 7, 2015 at 5:03 PM
> To: "mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu <mailto:mitreid-connect at mit.edu>>
> Subject: Introspection -> active true for expired tokens?
> 
> Hi,
> 
> We received reports about the “active” field returned by Introspection being true even when the provided token is expired. Looking at DefaultIntrospectionResultAssembler:assembleFrom I see that it unconditionally sets that field to true. Is this by design?
> 
> Note that we do have some overriding pieces in our deployment so it could be side effect from something on our side. We are NOT overriding the IntrospectionEndpoint or OAuth2TokenEntityService, either could be validating the token before proceeding, but I don’t see checks there either.
> 
> Regards,
> Luiz
> _______________________________________________
> 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/20151207/e12c5661/attachment-0001.html