Closed darena-mhaque closed 3 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?
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:
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:
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
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.
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?
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.
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:
Yes, try again
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.
Thanks!
This has hopefully been resolved by #391, which has not yet been deployed.
Fix is released in v2.9.0
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:
I am retrieving the id token from clicking on the "Inputs" tab:
Here is the decoded token in jwt.io:
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