Inrupt pod login complains about an invalid_client

I’ve in the past created my own Solid authorization client Web::Solid::Auth - A Perl Solid Web Client - that seems to work for the Node and services using the DPoP authentication method.

Now I’m trying to update my code so that it also works for the newest, shiniest, pods. I’m using, the latest Solid OIDC Primer from October 4 2021 as my guide for this.

The primer describes how I should publish a client_id document. So far so good, here it is:

Next I need to do an authorization request which should include the client_id plus redirect_uri (as specified in the client_id document). When I send this all to it just resonds with a JSON error resonse:

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

Is there some extra magic needed? What am I missing here?

I tried changeing the redirect_uri’s to public accessible servers, but that didn’t work.

1 Like

I think
@zwifi has worked on the js lib and could help

1 Like

It sounds like you are using static client id, is that right? i.e., Does support that? So far all my use has been with dynamic registration.

Right, it was not clear for me how to figure out what types of clients are supported by what type of platform.

1 Like

That’s an excellent question. I’d too like to know the answer. I’d really like to have a document/page that explains the differences across different platforms/servers.

1 Like

That’s an excellent question. Supported features should be discoverable through the .well-known/openid-configuration document. The Solid-OIDC specification mandates that an Identity Provider should specify its support for the specification required features by including "solid_oidc_supported": "" in its configuration document. However, the specification being still a moving target, this doesn’t solve all of the issues. That’s where the automated test suite comes into play: hopefully, we can write tests for each specification feature, and publish the results so that it’s clear what is supported by whom. In the meantime, we may need to manually document this, I opened a related specification issue to see what can be done.

All this to say that yes, Client ID documents are supported by You’ll notice that the error message mentions that the client is remote, which is specific to Client ID documents, so the Identity Provider understood the intent, but it looks like the identifier doesn’t match the expected shape. Nothing jumps at me looking at the client document, but could you provide the whole request to the authorization endpoint for additional context ? For instance, can you confirm that the provided redirec_uri matches exactly http://localhost:3000/callback (no additional slash or query parameters) ?

PS: thanks @Smag0 for tagging me :slight_smile:


Thanks for this clarification! I’ve tested again and it all runs smoothly now. Maybe a temporary hiccup. It would be great to have a clarification in in the documents (human,machine readable) which kinds of clients are supported by an Pod/

To try this out myself, I made a client id document:

And I made this authorization request:

And I get what hochstenbach initially reported:

Screen Shot 2021-10-16 at 9.56.31 PM

And the situation doesn’t change after trying it a few times.


Indeed, also at my end I have again the same issue with the request that worked 5 days ago. It seems to be a temporary issue at the broker service at Inrupt.

This is my request:

@zwifi Any thoughts on this? Thanks!