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

[Luiz Omori]

Oh, we also found out that as a side effect related to duplicated ID tokens being generated the window where active==true returned by the Introspection endpoint for ID tokens is much larger than 5min. Depending on the load, maybe days. This will affect versions prior to the JTI being added to ID tokens, like the one used by SMART on FHIR.

Regards,
Luiz

From: Luiz Omori <luiz.omori at dm.duke.edu<mailto:luiz.omori at dm.duke.edu>>
Date: Tuesday, December 8, 2015 at 9:33 AM
To: Justin Richer <jricher at mit.edu<mailto:jricher at mit.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?

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/20151210/6cad1381/attachment.html