reports invalid_client

I’m trying to create some Go code to access private data in my inrupt pod. When my code go through the authorization flow

I get the following error from

{"error":"invalid_client","error_description":"Invalid remote client"}

The full URL is

Here’s the parsed value.

{'client_id': [''],
 'nonce': ['4m1Cp2jRsB4w9ESTYFa-KQ'],
 'redirect_uri': ['http://localhost:9080/auth/callback'],
 'response_type': ['code'],
 'scope': ['openid'],
 'state': ['5__jB6iWzuho6tWAoLeZiw']}

I saw a previous topic on this problem but there didn’t seem to be any clear resolution.

My code is available here

Any help is greatly appreciated; thank you.

1 Like

This could be that the document contains invalid JSON, or at one point did. ESS caches public client identifiers for up to 2 hours, so you may be seeing the result of that.

I’ve just checked your public client identifier document, and it looks well formed, though.

Thanks for the quick reply. Any suggestions on how to debug further?

Just in case it’s useful information, I wasn’t able to add client identifiers either due to lack of debuggability.

Okay, I’ve an update: it may be because github serves the document as text/plain potentially. The document looked fine though, so I’d suggest storing it in a pod.

Oh! It might be good to update the documentation to state that it needs to be served with a particular content type ( application/ld+json?), as that might’ve been my problem either.

(I did consider uploading it to a Pod, but stopped short of doing that because I’d need to write a script to upload it with the right content type, without knowing whether that was the issue. A Client ID uploader/creator app might be a fun little app for someone at Inrupt to create :slight_smile: I might find some time to do some yak shaving and do it myself at some point, but not in the super short term.)


Thank you @ThisIsMissEm that fixed the issue. Is there someplace I can file a request for more informative error messages? It looks like I hit two problems with my client id document

  1. The content-type of the response was text/plain and not application/json
  2. The client_id in the document didn’t match the URI I was hosting it on (after I moved it to solid storage).

Both of these seem like errors the OIDC server could easily detect and provide actionable error messages for.

1 Like

Having content-negotiated errors which can render to HTML and contain more information is on the roadmap of ESS already, and I’ll share your feedback with the team so that they have this specific case in mind.

In general, feedback about proprietary Inrupt products can be sent to Jira Service Management :slight_smile: