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

[Luiz Omori]

Will do.

As far as I can tell (debugger not quite working at the moment) IntrospectionEndpoint::verify is calling OAuth2TokenEntityService::readAccessToken and in DefaultOAuth2ProviderTokenService implementation that method is missing the accessToken.isExpired check. Interesting that this check is made in other methods within that class but not there. Fix should be easy.

Regards,
Luiz

From: Justin Richer <jricher at mit.edu<mailto:jricher at mit.edu>>
Date: Monday, December 7, 2015 at 5:58 PM
To: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Cc: "mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>" <mitreid-connect at mit.edu<mailto:mitreid-connect at mit.edu>>
Subject: Re: [mitreid-connect] Introspection -> active true for expired tokens?

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<mailto: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<mailto: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/20151208/8d17176f/attachment.html