onc-healthit / inferno-community

Archived source code for the Inferno Testing Tool and the Community Edition set of tests. No longer maintained.
https://inferno.healthit.gov/
Apache License 2.0
92 stars 35 forks source link

OpenID Connect "iat" invalid claim #351

Closed darena-mhaque closed 3 years ago

darena-mhaque commented 4 years ago

Subject of the issue This used to pass before, but it no longer does. Either in the standalone launch or the ehr launch, the section open id connect, test number 6, always displays "Invalid iat". There aren't any further details as to why it is invalid.

Here is the test result: image

I am retrieving the id token from clicking on the "Inputs" tab: image

Here is the decoded token in jwt.io: image

Everything seems fine to me...

Your environment

Steps to reproduce Follow through with the standalone or ehr launch sequences as normal. The error will occur once the sequence has completed.

Expected behavior ID token validation should pass

Actual behavior ID token validation fails with "Invalid iat" error.

Please let me know if there is any additional information required

Jammjammjamm commented 4 years ago

That test has not been updated recently. The above iat claim looks like it's in the proper format, so I believe that the only reason it would be invalid would be that it represents a time in the future. The test is configured to allow 30 seconds of leeway, so to an invalid iat would have to represent a time more than 30 seconds in the future.

Can you do a launch and use this tool to compare the iat timestamp to the current UTC time?

darena-mhaque commented 4 years ago

So after trying this out a little more. It seems to be inconsistent. Sometimes I would pass the validation. Sometimes I would not...

Here is the most recent scenario where I did not pass validation. Below I have a screenshot of when I was redirected back to the test tool: image

Taking the id token to jwt.io, I can see that the iat is listed as 11:40:45 in my local time, a 15 second difference: image

Keep in mind it did take me a few seconds to take the screenshot, so the gap should be smaller, maybe a difference of 10-13 seconds at most.

I have also used the epoch converter tool you mentioned, it lists the same time: 11:40:45

SavannahDearing commented 4 years ago

After hard-coding a temporary solution for my other problem, I'm also getting this error. I've tried subtracting 10, 30, 60 seconds to see if it effect the outcome, but I still get this error. I'm able to verify the time difference is not greater than 30 seconds using the converter tool linked. It shouldn't matter since we're using epoch time, but I'm also on EST.

Jammjammjamm commented 4 years ago

Yeah, this is difficult to debug if I can't check the server time and token time when this actually happens. I've never seen this error when running the deployed or local versions of Inferno. Are either of your systems open so that I could try do a launch and inspect the token in real time?

SavannahDearing commented 4 years ago

I'm using the web version launched from https://inferno.healthit.gov/inferno/ Fhir Server: https://www.medentmobiletest.com/fhir/DSTU2/savcw235 client_id: 1234567890 client_secret: 12345678901234567890 patient login: iattest /1234567

This connects to data that has no real PHI on it, but all the same let me know when you're done so I can disable this connection. This connection might also fail sometime between 5pm-8am as I may need to rebuild the programs due to updates.

Jammjammjamm commented 4 years ago

Can that client id/secret be setup to use these launch/redirect urls?

http://localhost:4567/inferno/oauth2/static/launch
http://localhost:4567/inferno/oauth2/static/redirect

I get a forbidden OperationOutcome when running locally, which I'm guessing is due to the unrecognized launch/redirect urls. I'm getting SSL errors when I try to run from the deployed version:

Screen Shot 2019-12-04 at 3 45 09 PM

SavannahDearing commented 4 years ago

Yes, try again

Jammjammjamm commented 4 years ago

It does look like the time contained in iat is correct, so this will require some additional investigation on my part.

Server time: 1575493352
JWT time:    1575493350

I'm able to generate JWTs the duplicate this error, so I shouldn't need access to your server anymore.

SavannahDearing commented 4 years ago

Thanks!

Jammjammjamm commented 4 years ago

This has hopefully been resolved by #391, which has not yet been deployed.

yunwwang commented 3 years ago

Fix is released in v2.9.0