nodeSolidServer / nodeSolidServer/node-solid-server

Dynamic client registration accepts form encoded data but parses it incorrectly

Open
#1,564 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
1.8k
Forks
308
PR merge metrics
No merged PRs in 30d

Description

I'm writing a python library to perform webid-oidc, according to the guide at https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md

At step 9 (Dynamic client registration), there is a link to https://openid.net/specs/openid-connect-registration-1_0.html
The spec says in section 3.1:

The Client sends an HTTP POST to the Client Registration Endpoint with a content type of application/json

I was initially sending form encoded data to this endpoint, but node-solid-server accepted the request:

A python request of:

    data = {
        "grant_types": ["implicit"],
        "issuer": "https://localhost:8443",
        "redirect_uris": ["https://localhost:8443/redirect"],
        "response_types": ["id_token token"],
        "scope": "openid profile"
    }
r = requests.post("https://localhost:8443", data=data, verify=False)

results in an HTTP request of:

POST / HTTP/1.1
Host: localhost:8899
User-Agent: python-requests/2.25.1
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Content-Length: 164
Content-Type: application/x-www-form-urlencoded

grant_types=implicit&issuer=https%3A%2F%2Flocalhost%3A8443&redirect_uris=http%3A%2F%2Flocalhost%3A8888%2Fredirect&response_types=id_token+token&scope=openid+profile

node-solid-server accepts this request and adds to db/oidc/op/clients a file with the contents

{
  "redirect_uris": "http://localhost:8888/redirect",
  "client_id": "a1b6275fa73f653a7392f5440851356b",
  "client_secret": "bdc6c73d1f6f4de3ded9f43a730a7d86",
  "response_types": "id_token token",
  "grant_types": "implicit",
  "application_type": "web",
  "id_token_signed_response_alg": "RS256",
  "token_endpoint_auth_method": "client_secret_basic"
}

Note that it no longer includes the lists in the original request for grant_types, redirect_urls or response_types.

If I send the data as a json body with the correct content-type, the data is accepted correctly and generates the following client file:

{
  "redirect_uris": [
    "http://localhost:8888/redirect"
  ],
  "client_id": "805187586c656faad7ad21e05c7d08b8",
  "response_types": [
    "id_token token"
  ],
  "grant_types": [
    "implicit"
  ],
  "application_type": "web",
  "id_token_signed_response_alg": "RS256",
  "token_endpoint_auth_method": "client_secret_basic"
}

The incorrect data in the clients file results in an exception when trying to access the authorize url, because a list is expected when looking at the redirect_urls field: https://github.com/solid/oidc-op/blob/72e4cfa7870aab7913314cbbe5277d0bb559dcf8/src/handlers/AuthenticationRequest.js#L511

It's clear that I was submitting data in the wrong format, but node-solid-server still accepted it, even though the specification says that the content-type should be application/json (I see that it doesn't make a MAY/SHOULD/MUST claim here though...). Perhaps it makes sense for node-solid-server to return HTTP400 if the data format is incorrect?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with src/handlers/AuthenticationRequest.js at the linked line, where the malformed client data later causes an exception, then trace how dynamic registration parses form-encoded requests. Done means incorrect content types or shapes are rejected with HTTP 400 while valid application/json registration continues to preserve its array fields.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, node.js
Domain
api, authentication, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.