Stream: bulk data
Topic: Servers
Grahame Grieve (Jan 22 2018 at 22:42):
thanks @Dan Gottlieb . do you know of any API differences between my server and yours?
Dan Gottlieb (Jan 23 2018 at 00:21):
I think the main API difference is how they handle requests where no data is found - your server returns 200 and a link to an empty bundle and the SMART server returns a 204. Also, it looks like your server is returning links to a bundle.ndjson and a .zip(?) file in addition to the resource ndjson files, while the SMART server only returns the resource ndjson files.
Dan Gottlieb (Jan 23 2018 at 00:22):
Does your server support the backend services auth API? If so, how can I register a client to test it out?
Grahame Grieve (Jan 23 2018 at 15:52):
yes supports back-end services
Grahame Grieve (Jan 23 2018 at 15:53):
to register a client, use your browser to login through https://test.fhir.org/r3
Grahame Grieve (Jan 23 2018 at 15:53):
.. which doesn't work...
Grahame Grieve (Jan 23 2018 at 16:04):
while I'm debugging that...
Grahame Grieve (Jan 23 2018 at 16:06):
I think it's worth returning the bundle. It can help to determine the structure of the data returned. I don't have a solid use case to present right now for why that might matter, but the data returned might be a fairly deep web, and the bundle will help determine which are proximal resources, if you care
Grahame Grieve (Jan 23 2018 at 16:07):
and it's because I always return the bundle, which all the information in it, that I don't return a 204
Dan Gottlieb (Jan 23 2018 at 16:24):
The single bundle could potentially have millions of entries though - I thought that was one of the things we were trying to avoid?
Dan Gottlieb (Jan 23 2018 at 16:24):
Also, how would this be used - if the client loads and parses the bundle they still have to etl the ndjson files for it to be any use, at which point they have the same data in the db?
Grahame Grieve (Jan 23 2018 at 16:27):
the bundle is split at entry.resource - so the ndjson files are all still one resource type, and resources are not carried twice
Dan Gottlieb (Jan 23 2018 at 16:30):
It looks like it has a fullUrl for each resource though - for a few hundred thousand paitents, wouldn't this be millions of rows?
Grahame Grieve (Jan 23 2018 at 16:31):
yes it could be plenty. It would still be a small % of the total though
Dan Gottlieb (Jan 23 2018 at 16:40):
I wonder if we should return an index to the files in the body of the final status response instead of having the links header and the bundle file. It would enable us to include metadata like the transaction date, whether auth is needed to download the files, and number of resources in each file. Also, implementers won't have to worry about bumping into header size restrictions.
Dan Gottlieb (Jan 23 2018 at 16:40):
It does break the paradigm of the client not having to parse anything but headers though, which is a nice flow.
Grahame Grieve (Jan 23 2018 at 16:50):
it wouldn't be a substitute for the bundle directly, in that form at least. it carries other infomration
Grahame Grieve (Jan 23 2018 at 16:51):
I'm not sure how significant the header size issue is. the HTTP/2.0 analysis said that it was normal to see 8k+ of headers
Grahame Grieve (Jan 23 2018 at 16:51):
but i don't recall whether that analysis was scope limited
Dan Gottlieb (Jan 23 2018 at 16:56):
What info is in the bundle that we need to get to clients? We've talked about transaction date and possibly resource count - are there other items?
Grahame Grieve (Jan 23 2018 at 17:05):
fundamentally the element of interest is entry.search.mode, though I think it's use is ambiguous for $everything
Josh Mandel (Jan 24 2018 at 00:20):
For http, of course we're targeting http/1.1 support here too. I understand nothing about long headers is against the protocol, but going against the grain of default server configurations could be painful (or not...)
Josh Mandel (Jan 24 2018 at 00:36):
For the bundle, hmm, I'm still not sure I understand -- is it that the bundle contains one entry for every unique resource returned (i.e. the number of entries in like wc -l *.ndjson if you've downloaded all the ndjson files?)
Grahame Grieve (Jan 24 2018 at 03:48):
my bundle does. It was my intent that it would be useful to allow you to know whether a resource is directly linked to a patient, or brought in by chasing the graph. This is most relevant for resources that are affected by the $list considerations, (which are current medications, vs other past records of medications). But it may be that Bundle.entry.search.mode is a very blunt device for that tricky problem even if we clarified it's usage
Grahame Grieve (Jan 24 2018 at 11:59):
@Dan Gottlieb : server login using OAuth is fixed - login to my server using OAuth at https://test.fhir.org/r3, and then choose 'register a client' , with mode = backend services client
Grahame Grieve (Jan 24 2018 at 12:00):
I can create you an account if you won't want to use HL7/facebook/google identity providers
Grahame Grieve (Jan 24 2018 at 12:01):
@Josh Mandel - my comments about HTTP/2.0 were referring the source analysis the WG used when optimising http/2.0: it was analysis of how http/1.1 is actually being used
Dan Gottlieb (Jan 24 2018 at 17:10):
@Grahame Grieve It times out when I click the login through google link. When I tried with hl7, I got this error "The state does not match. You may be a victim of a cross-site spoof (or this server has restarted, try again)".
Vladimir Ignatov (Jan 24 2018 at 17:26):
I made a sample CLI client for bulk data servers (https://github.com/smart-on-fhir/sample-apps-stu3/tree/master/fhir-downloader) and I am currently trying to make it compatible with https://test.fhir.org/r3. While doing that I noticed some interesting behavior that is probably worth discussing:
After I manage to get through the entire flow and try to download a file, I still have to provide an "Accept: application/fhir+ndjson". Otherwise I receive an error saying:
Mime Type mismatch. Original request was for application/x-ndjson, current request is for ""
I wonder if this should be added to (or removed from) the spec? Is that really needed at this point?
Vladimir Ignatov (Jan 24 2018 at 20:47):
Also, is the _type parameter implemented there? I was trying with http://test.fhir.org/r3/Patient/$everything?_type=CarePlan,Claim&start=2016 but it returns all kinds of resources.
Grahame Grieve (Jan 24 2018 at 22:32):
@Dan Gottlieb did you go back? that's an issue I haven't got around to resolving - if you try one kind of authentication, you have to refresh the form if you go back
Grahame Grieve (Jan 24 2018 at 22:34):
@Vladimir Ignatov - I will drop the requirement that accept must not be empty. But it must be correct if present
Grahame Grieve (Jan 24 2018 at 22:34):
e.g. you can't, at this point, ask for xml after all
Grahame Grieve (Jan 24 2018 at 22:35):
and no, my server doesn't support the _type parameter at this point
Dan Gottlieb (Jan 25 2018 at 14:49):
@Grahame Grieve In each instance I started from test.fhir.org/r3 and cleared my cookies. I just tried it again and am having the same issues. Do you know if the social login is working for other folks?
Josh Mandel (Jan 25 2018 at 15:46):
(Trying now... the redirect back to test.fhir.org from Google seems to hang; test.fhir.org isn't serving up a page.)
Grahame Grieve (Jan 26 2018 at 00:58):
hmm. it works for me on my debug version... how useful....
Grahame Grieve (Jan 26 2018 at 02:31):
seems as if the issue is lack of memory on the server.... bumping it's size up now
Josh Mandel (Jan 26 2018 at 05:55):
That did the trick, thanks!
Grahame Grieve (Jan 26 2018 at 09:08):
great.
Informatics User (Mar 13 2018 at 17:37):
Are there any EHR vendors (eg, Epic) who plan to pilot bulk export functionality?
Dan Gottlieb (Mar 14 2018 at 14:34):
A number of EHR vendors will be exploring the bulk data effort in 2018 as part of the HL7 Argonaut Project (which includes Epic, Cerner, athenahealth, Meditech, McKesson, and others vendors), but have not yet committed to specific pilots: http://www.hl7.org/documentcenter/public_temp_6FECF0C3-1C23-BA17-0CB268745144461B/pressreleases/HL7_PRESS_20180227.pdf
Isaac Vetter (Mar 15 2018 at 04:22):
Hi Vojtech/@Informatics User , To add on to Dan's answer -- Epic specifically should have a prototype server (and hopefully client too!) by the May connectathon. By the Sept connectathon, our prototype will be more stable. Let me know if you're specifically interested in testing with Epic.
Karen Fairchild (Sep 07 2018 at 18:30):
Isaac - is your Epic Bulk Data server available? We would like to test with it and we will be at the Sept Connectathon.
Isaac Vetter (Sep 07 2018 at 18:31):
Hi @Karen Fairchild - oh man, almost. We've been working on getting it all setup for the past couple of weeks. Will you ask @Justin Stauffer and I this question again next week?
Karen Fairchild (Sep 07 2018 at 18:32):
Will do! Thanks for the update!
Jenni Syed (Sep 07 2018 at 19:52):
I'm updating our URL on the documentation, but the Cerner server is up: https://fhir-open.stagingcerner.com/r4/a758f80e-aa74-4118-80aa-98cc75846c76/Patient/$export
Jenni Syed (Sep 07 2018 at 19:52):
There may still be some data issues, let us know if you find something
Jenni Syed (Sep 07 2018 at 19:52):
Currently no OAuth support
Karen Fairchild (Sep 11 2018 at 15:48):
Is this supposed to have security or not? We are having issues connecting to your server.
Karen Fairchild (Sep 11 2018 at 15:49):
Jenni - is your Cerner bulk data server secured or not? We are having issues connecting to it.
Karen Fairchild (Sep 12 2018 at 14:14):
@Jenni Syed - still having issues connecting to your Cerner bulk data server. What if any security is required for https://fhir-open.stagingcerner.com/r4/a758f80e-aa74-4118-80aa-98cc75846c76/Patient/$export
Jenni Syed (Sep 12 2018 at 14:36):
Should be none - what error are you seeing? What is the X-REquest-Id value returned with the error?
Karen Fairchild (Sep 12 2018 at 15:41):
Thanks. @Jenni Syed We thought it needed a token -- we'll take that out and retry it.
Karen Fairchild (Sep 14 2018 at 17:25):
@Jenni Syed -we processed data from your Cerner bulk data server and were able to correlate the clinical data with the patient data. We did not see any MR (Medical Record Number) identifiers in your data. Are you able to populate MRNs? We use that for the bulk data "de-id" view for researchers. Also noticed no race or ethnicity. I realize those are argonaut extensions but If you had race or ethnicity we would be pulling that data also for the research scenario in the connectathon also. @Isaac Vetter - will Epic have MRNs for the connectathon?
Karen Fairchild (Sep 17 2018 at 14:37):
@Isaac Vetter @Justin Stauffer
Karen Fairchild (Sep 17 2018 at 14:38):
@Isaac Vetter @Justin Stauffer checking in on the Epic bulk data server - ETA for when it is ready - also, will Epic be able to supply an MR type identifier for patient medical record numbers - we were planning on using that to assign a pseudo patient identifier of type ANON in the patient resource in the connectathon for the "research" view of bulk data.
Justin Stauffer (Sep 18 2018 at 13:26):
We're still working on some setup for the Epic FHIR Bulk Data Server. It shouldn't be much longer. I'm not 100% clear on your question about the patient identifiers but in addition to returning the FHIR ID for a patient resource, we also return other MRNs for the patient that we have on file.
Michele Mottini (Sep 18 2018 at 15:19):
How long did it take to get the data from the Cerner server? My client has been running for more than 30 minutes and still not done
Michele Mottini (Sep 18 2018 at 15:19):
...also, I guess the Cerner server returns R4 resources? ...any chance to have STU3 or (even better) DSTU2 ?
Dennis Patterson (Sep 18 2018 at 15:21):
There was a discussion on https://chat.fhir.org/#narrow/stream/95-bulk-data/subject/Gzip.20compression.20on.20Cerner.20staging.20server, but I'm planning to make gzipped ndjson fields available for download
Dennis Patterson (Sep 18 2018 at 15:22):
Our connectathon Server will fall under the r4 path (dstu2 is in production and stu3 is under development), but I mentioned on the kickoff call that I'll be aiming for STU3 compliance on those files... they likely already are
Michele Mottini (Sep 18 2018 at 15:46):
...completed in 50 minutes, that's a lot of data! (that I actually failed to download...working on that)
Karen Fairchild (Sep 18 2018 at 17:14):
@Justin Stauffer - thanks Justin. Glad to hear you will popoulate MRNs in the Patient structure where you have them as we will use those for our de-identification use case.
Dennis Patterson (Sep 18 2018 at 19:56):
@Karen Fairchild I noticed your request about the Cerner server. My priority right now is uplifting the API to the newest version of the spec, making some hosting changes to our mock data, and then digging into the Backend Services spec. I have noted the desire for MRNs and race/ethnicity extensions, but can't make any promises for the connectathon timeline
Karen Fairchild (Sep 18 2018 at 20:04):
Thanks!
Justin Stauffer (Sep 19 2018 at 14:38):
OK, I think our test bulk data server is up and ready to go. The URL is as follows:
https://connectathon.epic.com/interconnect-fhir-bulk/api/FHIR/STU3/Group/ebUKRzWjCOkHtNr8R-zHgzc4TdaZx9-TOvXKIeP0bLnM3/$export
Some things to note:
- You'll notice I provided a Group ID in the URL above – this is the only Group I have defined on the test server right now and it should return data for 2 patients. We do not support the "all patients" or "system level export" options.
- Right now this test endpoint does not currently require OAuth2 but that will be subject to change as we're testing things at the Connectathon.
- Since we're not requiring OAuth2 but we still need to know who is requesting the data from our test endpoint, we require clients to provide a custom HTTP header identifying themselves. This header is called "Epic-Client-ID" and you will need to specify one of the Client IDs mentioned below. So for example, the header would look like this:
Epic-Client-ID: JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ01
I have a few such example client IDs that will allow multiple bulk data clients to request the same group's data at once since we normally only allow a particular client to request the so often (I think it's once per day or something along those lines). These test Client IDs are: JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ01, JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ02, JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ03, and JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ04.
- You'll also notice our complete status response always returns requiresAccessToken=true right now. This is because we never intend to use this in an unsecured fashion in the real world so I just hard-coded that. If that's an issue for some clients at the Connectathon, I can probably tweak that logic.
- The resources returned are STU3.
Josh Mandel (Sep 19 2018 at 15:22):
To be pedantic, I should say that "requiresAccessToken: false" doesn't mean that a system is insecure; it just implies that any required authentications is baked into the URL (e.g., a URL with a signed authentication parameter baked in).
Josh Mandel (Sep 19 2018 at 15:24):
(deleted)
Josh Mandel (Sep 19 2018 at 15:24):
For the connnectathon, if you're hard coding rules, can you relax the once daily restriction?
Josh Mandel (Sep 19 2018 at 15:26):
Otherwise, four client IDs would mean that only eight exports could be performed all weekend, if I understood correctly? In my experience during testing and debugging, we are likely to need to kick off several hundred exports each.
Josh Mandel (Sep 19 2018 at 15:26):
@Justin Stauffer
John Moehrke (Sep 19 2018 at 15:46):
we likely need to identify a set of reasonable alternative security models and describe how they are declared in CapabilityStatement. Such as mutual-authenticated-TLS (IHE-ATNA), or API-KEY and https, or ??? The security wg would love to help, but we need the active development environment to come up with some patterns. Note that no pattern will ever be perfectly secure, so we should not be afraid of being realistic. Also, some data does not require transport security (de-identified data assessed as publicly exportable)
Justin Stauffer (Sep 19 2018 at 17:07):
@Josh Mandel Yeah, I can mess with those rules as needed. That's not a problem.
Justin Stauffer (Sep 20 2018 at 14:55):
Oh, and if anyone foresees their system having an issue with my non-GUID client IDs, please let me know. I may adjust them anyway but we don't /really/ care what the client ID is as long as it's unique to us.
Karen Fairchild (Sep 24 2018 at 18:13):
@Justin Stauffer - just checking to see if you are doing gzip files from your bulk data server or are they the original standard ndjson files?
Justin Stauffer (Sep 25 2018 at 20:52):
@Karen Fairchild We return the raw ndjson files (no zipping).
Karen Fairchild (Sep 25 2018 at 22:37):
Thanks @Justin Stauffer
Justin Stauffer (Sep 29 2018 at 13:29):
@Karen Fairchild Here is an example request that I've sent from Fiddler with HTTP headers, etc.:
HTTP GET to: https://connectathon.epic.com/interconnect-fhir-bulk/api/FHIR/STU3/Group/ebUKRzWjCOkHtNr8R-zHgzc4TdaZx9-TOvXKIeP0bLnM3/$export
HTTP Headers:
User-Agent: Fiddler
Host: connectathon.epic.com
Content-Type: application/fhir+json
Accept: application/json
Epic-Client-ID: JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ01
Content-Length: 0
Justin Stauffer (Sep 29 2018 at 14:29):
Epic OAuth2 secured server info:
OAuth2 Token Endpoint (expecting Client Credentials with JWT): https://connectathon.epic.com/interconnect-fhir-oauth/oauth2/token
Secured Bulk Data server URL: https://connectathon.epic.com/interconnect-fhir-bulk-secure/api/FHIR/STU3/Group/ebUKRzWjCOkHtNr8R-zHgzc4TdaZx9-TOvXKIeP0bLnM3/$export
You must use this client ID to make a request for the token: 4E5DF30EC3EF11E8845F0050568B2116
I have a certificate created that I can send you the keys for as well (I'm just doing manual client registration right now so I thought that would be easiest to supply the key).
Dan Gottlieb (Sep 29 2018 at 14:35):
@Justin Stauffer @Dennis Patterson we posted some sample keys on the bulk data docs repo so people don't have to host jwks files for testing. Is it possible to register these too? https://github.com/smart-on-fhir/fhir-bulk-data-docs/tree/master/sample-jwks
Dennis Patterson (Sep 29 2018 at 14:36):
Sure I'll get to work registering these in the Cerner server
Justin Stauffer (Sep 29 2018 at 15:20):
This zip file has the key data for Epic. There are multiple representations of the keys in here to make it easy for people using different systems.
Public Key: connectathon-2018-09-a.cer
Private Key: connectathon-2018-09-a.key (encrypted with the password "epic")
Private Key Unencrypted: connectathon-2018-09-a-unencrypted.key (not encrypted, in base64 format)
Combined Pub/Priv Key (PEM): connectathon-2018-09-a.pem (encrypted with password "epic")
Combined Pub/Priv Key (PFX): connectathon-2018-09-a.pfx (encrypted with password "epic")
Public Key in RSA Crypto Form: connectathon-2018-09-a-rsacrypto-pub.txt
Private Key in RSA Crypto Form: connectathon-2018-09-a-rsacrypto-priv.txt
HL7-Connectathon-2018-09.7z
HL7-Connectathon-2018-09.zip
Dennis Patterson (Sep 29 2018 at 15:25):
@Dan Gottlieb and others: I've registered the sample jwks in the Cerner server under the "sample_jwks_es384" and "sample_jwks_rs384" client ids
Dan Gottlieb (Sep 29 2018 at 15:26):
@Dennis Patterson awesome!
Dan Gottlieb (Sep 29 2018 at 15:26):
One note - we've discovered you have use the rawgit service to get a proper content type on the key files. For example, https://cdn.rawgit.com/smart-on-fhir/fhir-bulk-data-docs/master/sample-jwks/ES384.public.json .
Dan Gottlieb (Sep 29 2018 at 15:27):
Is it possible to alter the jwks url for the registered keys?
Dennis Patterson (Sep 29 2018 at 15:28):
I used https://raw.githubusercontent.com/smart-on-fhir/fhir-bulk-data-docs/master/sample-jwks/ES384.public.json which I think gets the same results
Josh Mandel (Sep 29 2018 at 15:28):
Yes, save for content type headers
Dan Gottlieb (Sep 29 2018 at 15:29):
It should, but it returns a content type of text instead of JSON. This broke the SMART server, but may work with yours :)
Dennis Patterson (Sep 29 2018 at 15:29):
gotcha
Dennis Patterson (Sep 29 2018 at 15:33):
I did some testing and it doesn't choke on the content type header, but I'll push out the change for consistency on the next deployment. If anybody tries these client ids, let me know if you run into any issues
Dan Gottlieb (Sep 29 2018 at 18:38):
@Dennis Patterson the SMART client now works your server!
Justin Stauffer (Sep 29 2018 at 20:28):
If you want to use the shared RSA key that Dan posted to access the Epic URL, you can do so now as long as you use this Client ID to obtain your access token: DD794EAEC42511E88BE00050568B2116
Michele Mottini (Nov 08 2018 at 13:51):
@Vladimir Ignatov : cannot use the SMART bulk data test server - it gives me Unable to verify the token with any of the public keys found in the JWKS, not sure what changed
Michele Mottini (Nov 08 2018 at 13:51):
I tried to re-create the client id, double-checked the client credentials, everything seems fine
Michele Mottini (Nov 08 2018 at 13:52):
Client assertion that fails: eyJ0eXAiOiJKV1QiLCJrdHkiOiJSU0EiLCJhbGciOiJSUzM4NCIsImtpZCI6IjY2NjJGMkY4MUMxQTQ1QTcxNTNEREI3NUM4MjJCNjY3M0U2RTdBMjkifQ.eyJpc3MiOiJleUpoYkdjaU9pSklVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXRwWkNJNkluSmxaMmx6ZEhKaGRHbHZiaTEwYjJ0bGJpSjkuZXlKcWQydHpYM1Z5YkNJNkltaDBkSEJ6T2k4dlpHVnRieTVqWVhKbFpYWnZiSFYwYVc5dUxtTnZiUzlEVG1wM2RHTmhjbVZsZG05c2RYUnBiMjVqYjIwdWFuTnZiaUlzSW1GalkyVnpjMVJ2YTJWdWMwVjRjR2x5WlVsdUlqb3hOU3dpYVdGMElqb3hOVFF4TmpnME1ETTJmUS5MY2dYeTN5VEJtNFQ2bnN0XzBDVzg0T29wU24xUmwxbVc1azEtNGNTM2Z3Iiwic3ViIjoiZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0lzSW10cFpDSTZJbkpsWjJsemRISmhkR2x2YmkxMGIydGxiaUo5LmV5SnFkMnR6WDNWeWJDSTZJbWgwZEhCek9pOHZaR1Z0Ynk1allYSmxaWFp2YkhWMGFXOXVMbU52YlM5RFRtcDNkR05oY21WbGRtOXNkWFJwYjI1amIyMHVhbk52YmlJc0ltRmpZMlZ6YzFSdmEyVnVjMFY0Y0dseVpVbHVJam94TlN3aWFXRjBJam94TlRReE5qZzBNRE0yZlEuTGNnWHkzeVRCbTRUNm5zdF8wQ1c4NE9vcFNuMVJsMW1XNWsxLTRjUzNmdyIsImF1ZCI6Imh0dHBzOi8vYnVsay1kYXRhLnNtYXJ0aGVhbHRoaXQub3JnL2F1dGgvdG9rZW4iLCJqdGkiOiI1Njg2ZjdkMy03YzlkLTQ5MjUtOWM2My0xOTIxZDNmYmQ3YjMiLCJuYmYiOjE1NDE2ODQ0MjcsImV4cCI6MTU0MTY4NDcyN30.sa_ntw7ZcUbuFoGYRel4M-Jrx16GUmvKg8p7LGKnSVYm5WzPrx7EWZ_TOjxtl1d2t4Cw2AdF34ftcHjI8wTHXzMV1QgqXsPELFwUYPmp8xol54Fjx1wYkah0kraFJ8hED1nrjfTkm873M3lldELhAxCc7pMnTLFpepRG7R5ENepimP9uIqYyiAwYVKy5kbAWA839yb1Dolw4JSVqJEFFvbAiVCzi-_pLzFIugu1JWVRC3yYEY8uFJHkkurjEac7snd-pRo4E6u-aKn0vFc4NzcUFNb6FOXeBiHhZI6Rk1jq4spepvfUhxZTvW7uU3Ek2ZeCZSTzRrmqIUPD8J7kjpw
Michele Mottini (Nov 08 2018 at 14:11):
@Justin Stauffer : getting authentication problems with Epic server as well, using client ID 4E5DF30EC3EF11E8845F0050568B2116
Michele Mottini (Nov 08 2018 at 14:12):
Client assertion:
Michele Mottini (Nov 08 2018 at 14:12):
eyJ0eXAiOiJKV1QiLCJrdHkiOiJSU0EiLCJhbGciOiJSUzM4NCIsImtpZCI6IkQ3NjU0NDAyQkZDMzkzNzQyN0VBMzlBNTRBOTQzQUNENDlGNEU4MTYifQ.eyJpc3MiOiI0RTVERjMwRUMzRUYxMUU4ODQ1RjAwNTA1NjhCMjExNiIsInN1YiI6IjRFNURGMzBFQzNFRjExRTg4NDVGMDA1MDU2OEIyMTE2IiwiYXVkIjoiaHR0cHM6Ly9jb25uZWN0YXRob24uZXBpYy5jb20vaW50ZXJjb25uZWN0LWZoaXItb2F1dGgvb2F1dGgyL3Rva2VuIiwianRpIjoiYWU0YmM2ODgtN2U0MS00ZDBmLTk4NzgtYjBhMTM1ZjdjYzE3IiwibmJmIjoxNTQxNjg1NDY3LCJleHAiOjE1NDE2ODU3Njd9.WXdMO-9SHUMsL_YBMPA69xS0TnO-2RaDz5zGMWPL66Z0uLvjvoi6KFo6Ku8OXW828eYhvtP26ad-ysrFxZ8vA2n45jk18MRfqmXYBxZzb_rWpYMZwfz6DoJ8AYrgQXfzXv4_BNU4P6vsr1DN96xNgUszCdbiPESQY8CQv4JgJ9n6PDhIOdEIczxw1xtItVQ0XXP8p495OJhIcME4ZQyS5u83s1vfkkCd7HUENv5DV70rbnTqdrUyEX6dl4ShwIKk8ml3VPD-zt5uEGQCu44zkcSsiMkZh9aenTQz7STYoJU9xvjFytnW5Iigu4pXOBTVCsIki0n0I2gS-_nU3Kee1Q
Michele Mottini (Nov 08 2018 at 14:12):
Getting back invalid_client
Vladimir Ignatov (Nov 08 2018 at 15:54):
Nothing has changed in the last month. Could it be a change on your end?
Michele Mottini (Nov 08 2018 at 16:10):
It might well be, but I cannot find anything wrong: "kid": "6662F2F81C1A45A7153DDB75C822B6673E6E7A29", the client_id is:
Michele Mottini (Nov 08 2018 at 16:10):
{
"jwks_url": "https://demo.careevolution.com/CNjwtcareevolutioncom.json",
"accessTokensExpireIn": 15,
"iat": 1541684036
}
Michele Mottini (Nov 08 2018 at 16:11):
and that jwks_url resolves correctly
Michele Mottini (Nov 08 2018 at 16:11):
Maybe the server did not switch from daylight saving time?
Vladimir Ignatov (Nov 08 2018 at 17:02):
Here is your error log:
{ TokenExpiredError: jwt expired
at /app/node_modules/jsonwebtoken/verify.js:141:21
at getSecret (/app/node_modules/jsonwebtoken/verify.js:76:14)
at Object.module.exports [as verify] (/app/node_modules/jsonwebtoken/verify.js:80:10)
...
name: 'TokenExpiredError',
message: 'jwt expired',
expiredAt: 2018-11-08T13:45:27.000Z }
Michele Mottini (Nov 08 2018 at 17:04):
Ah ok, so it is a time-related problem - let me double-check that I am sending the right expiration time
Michele Mottini (Nov 08 2018 at 17:11):
So I sent that request at 8:40 AM EST = 13:40 UTC, with that expiration time - so it should not have been considered expired?
Michele Mottini (Nov 08 2018 at 17:11):
What's the current time now according to your server?
Vladimir Ignatov (Nov 08 2018 at 17:13):
2018-11-08T17:13:03.755563+00:00
Michele Mottini (Nov 08 2018 at 17:17):
looks right - let me try again
Michele Mottini (Nov 08 2018 at 17:23):
same error - I am sending "exp": 1541698009
Michele Mottini (Nov 08 2018 at 17:23):
that should be 17:26 UTC
Michele Mottini (Nov 08 2018 at 17:28):
the problem is not the expiration, is the nbf claim - removed that and it works
Vladimir Ignatov (Nov 08 2018 at 17:28):
Are you also adding some lifetime to the current timestamp? For example, 5 min in JS would be:
exp: Date.now()/1000 + 300, // 5 min
Michele Mottini (Nov 08 2018 at 17:29):
I was sending nbf = current time, exp = current time + 5 minutes
Michele Mottini (Nov 08 2018 at 17:29):
Now I am just sending exp = current time + 5 minutes and it works
Michele Mottini (Nov 08 2018 at 17:29):
I guess my clock is a bit later than your server one and that's enough to make the nbf not valid
Michele Mottini (Nov 08 2018 at 17:34):
I think I'll just remove the nbf claim - it just causes problems
Vladimir Ignatov (Nov 08 2018 at 17:36):
Yes, nbf seem confusing to me. Who knows how the underlying libraries will interpret it...
Michele Mottini (Nov 08 2018 at 17:41):
Agreed
Michele Mottini (Nov 08 2018 at 17:41):
Thanks Vladimir
Vladimir Ignatov (Nov 08 2018 at 17:44):
Sure
Last updated: Apr 12 2022 at 19:14 UTC
