Generic OAuth error "due to an internal error" for "invalid_client_metadata"

[Gregoor]

Hi there 👋🏼

Describe the bug

In prod OAuth fails for me with the following (it works in dev):

⨯ Error: OAuth "invalid_client_metadata" error: Failed to fetch client information due to an internal error
    at h.request (/var/task/web/.next/server/chunks/533.js:60:238928)
    at async c.authorize (/var/task/web/.next/server/chunks/533.js:60:227047)
    ... {
  response: Response {
    status: 400,
    statusText: 'Bad Request',
    headers: Headers {
      date: 'Mon, 25 Nov 2024 00:39:58 GMT',
      'content-type': 'application/json',
      'transfer-encoding': 'chunked',
      connection: 'keep-alive',
      'x-powered-by': 'Express',
      'access-control-allow-origin': '*',
      'access-control-allow-headers': '*',
      'cache-control': 'no-store',
      pragma: 'no-cache',
      'dpop-nonce': 'Jw-9j3pBbjXCne6NHHT01L4Yq3xGRWheJ45l-blIVMA',
      'access-control-expose-headers': 'DPoP-Nonce',
      vary: 'accept-encoding',
      'content-encoding': 'br'
    },
    body: undefined,
    bodyUsed: true,
    ok: false,
    redirected: false,
    type: 'basic',
    url: 'https://bsky.social/oauth/par'
  },
  payload: [Object],
  error: 'invalid_client_metadata',
  errorDescription: 'Failed to fetch client information due to an internal error',
  digest: '1499086769'
}

To Reproduce

This is my OAuth config:

const IS_DEV = process.env.NODE_ENV == "development";
const ORIGIN = IS_DEV ? "http://127.0.0.1:3000" : "https://skylights.my";

const abs = (s: string) => `${ORIGIN}/${s}`;

const SCOPE = "atproto transition:generic";
const REDIRECT_URI = abs("atproto-oauth-callback");

export const authClient = new NodeOAuthClient({
  clientMetadata: {
    client_id: IS_DEV
      ? `http://localhost?redirect_uri=${enc(REDIRECT_URI)}&scope=${enc(SCOPE)}`
      : `${ORIGIN}/oauth/client-metadata.json`,
    client_name: "Skylights",
    client_uri: ORIGIN,
    tos_uri: abs("tos"),
    policy_uri: abs("policy"),
    redirect_uris: [REDIRECT_URI],
    grant_types: ["authorization_code", "refresh_token"],
    response_types: ["code"],
    application_type: "web",
    scope: SCOPE,
    token_endpoint_auth_method: "none",
    dpop_bound_access_tokens: true,
  },
  ...stores
});

Hope I gave enough info, please let me know if not!

[mikestaub]

I get a 404 when I curl that endpoint, it needs to return the client-metadata.json content and it must match with what is passed to the NodeOAuthClient:

curl -vL https://skylights.my/client-metadata.json

I built a passport strategy you might want to try with your node app, or at least look at the working example: https://github.com/mikestaub/passport-atprotocol

[Gregoor]

Oops, I did a bad job of keeping this example in sync while I was trying things today. The new metadata URL is:
https://www.skylights.my/oauth/client-metadata.json (which does go through now, and the problem persists).

Thanks for the library as well, I will give it a read!

[Gregoor]

I thought the lack of keysets and a token endpoint auth method might be the culprit so, thanks to Tyler from Sill, I now have a locally working version with keys that looks like this:

const privateKeyPKCS8 = Buffer.from(
  process.env.PRIVATE_KEY_ES256_B64 as string,
  "base64",
).toString();
const privateKey = await JoseKey.fromImportable(privateKeyPKCS8, "key1");

const isDev = process.env.NODE_ENV == "development";
const origin = isDev ? "http://127.0.0.1:3000" : "https://skylights.my";

const abs = (s: string) => `${origin}/${s}`;
const enc = encodeURIComponent;

const SCOPE = "atproto transition:generic";
const REDIRECT_URI = abs("oauth/atproto-callback");

export const authClient = new NodeOAuthClient({
  clientMetadata: {
    client_id: isDev
      ? `http://localhost?redirect_uri=${enc(REDIRECT_URI)}&scope=${enc(SCOPE)}`
      : abs("oauth/client-metadata.json"),
    client_name: "Skylights",
    client_uri: origin,
    redirect_uris: [REDIRECT_URI],
    grant_types: ["authorization_code", "refresh_token"],
    response_types: ["code"],
    application_type: "web",
    scope: SCOPE,
    token_endpoint_auth_method: "private_key_jwt",
    token_endpoint_auth_signing_alg: "ES256",
    dpop_bound_access_tokens: true,
    jwks_uri: abs("oauth/jwks.json"),
  },

  keyset: [privateKey],
  
  ...stores
});

Unfortunately it still fails with the exact same error on prod :(

[Gregoor]

I am wondering if it would be possible to add info about which FetchError failed, maybe adding status code and path wouldn't be too much of an information leak?

atproto/packages/oauth/oauth-provider/src/client/client-manager.ts

Lines 121 to 128 in 3303ff1

	if (err instanceof FetchError) {
	const message =
	err instanceof FetchResponseError || err.statusCode !== 500
	? // Only expose 500 message if it was generated on another server
	`Failed to fetch client information: ${err.message}`
	: `Failed to fetch client information due to an internal error`
	throw new InvalidClientMetadataError(message, err)
	}

@matthieusieben would you be open to such a PR of mine (I saw you touching these lines last, hope it's not inappropriate that I tag you)?

Update: Sorry that didn't make sense, just realized that the original error is bubbled out as well.

[mikestaub]

invalid_client_metadata likely means they simply do not match. Can you try logging out the JSON of your client metadata on the server and then diffing it with the json response from your public endpoint?

[Gregoor]

I just logged authClient.clientMetadata and compared it with my endpoint's output. They are both exactly this:

{
    "application_type": "web",
    "client_id": "https://skylights.my/oauth/client-metadata.json",
    "client_name": "Skylights",
    "client_uri": "https://skylights.my",
    "dpop_bound_access_tokens": true,
    "grant_types": [
        "authorization_code",
        "refresh_token"
    ],
    "jwks_uri": "https://skylights.my/oauth/jwks.json",
    "redirect_uris": [
        "https://skylights.my/oauth/atproto-callback"
    ],
    "response_types": [
        "code"
    ],
    "scope": "atproto transition:generic",
    "token_endpoint_auth_method": "private_key_jwt",
    "token_endpoint_auth_signing_alg": "ES256"
}

Thanks for the idea, happy to investigate any avenue at this point 😵‍💫

[mikestaub]

strange, that looks good to me. The last thing I would try is removing the "refresh_token" from the metadata

[Gregoor]

No luck with that one either, appreciate the attempt tho!

[mikestaub]

How did you generate your private key? Here is a working example: https://github.com/mikestaub/passport-atprotocol/blob/main/scripts/generate-keys.js

[Gregoor]

A friend helped me solve it! It was something stupid that felt unrelated to me. I though my main domain was the one without WWW and that the one with redirected towards it. Turned out it was the other way around.

So the obtuse error because instead of getting a 200 for the client metadata it got a 308. It would be very helpful if that error would bubble out though, so I'll keep this issue open.

Thank you for holding my hand @mikestaub!

[matthieusieben]

Closing as #3135 will improve error reporting (in particular in the case of an invalid redirect).

[matthieusieben]

Thansk for the report