Re-check Mastodon OAuth clients before using

[justincox]

I'm unable to set up a connection to Mastodon 4.2.1 and receive the following error message:

Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method.

Is there a bug in Bridgy or did Mastodon change something that prevents the connection?

[snarfed]

Hmm! I'm not sure. holonet.social, right? Bridgy's Mastodon auth is working fine with other instances right now; I wonder if it's something specific to that instance.

I could debug a bit more if I had an account, but holonet.social says it's closed to new accounts right now, so I'm a bit stuck.

[justincox]

Thank you for checking. It's a personal server, so I'm the only user. I'll check with the host and see if there's something blocking the connection.

[justincox]

I checked with my host and this was thier response:

Well, I don't see any Brid.gy app in the oauth_applications in your database. So, Brid.gy did not issued the request to create the app (or it failed) before firing the authentication request. That's why you get that Client Authentication Failed error. Now, why that happened, I can't say because the if there was an error it was on Brid.gy side. The best way to debug this is to look into it with the Brid.gy devs to see if we could find what causes the request to create the app to fail or not be issued.

[snarfed]

That's very odd. Bridgy's records show that it created an app for holonet.social at 2023-09-15 04:45:11 UTC with client id 5im3Ar56XJV6nYBAy4z6f-dVqd3UKSHkVS9NQKW08-Y. Full details:

{
  "id": "14",
  "name": "Bridgy",
  "website": "https://brid.gy/",
  "redirect_uri": "https://brid.gy/publish/mastodon/finish\nhttps://brid.gy/mastodon/delete/finish\nhttps://brid.gy/mastodon/callback\nhttps://brid.gy/delete/finish\nhttps://brid.gy/micropub-token/mastodon/finish",
  "client_id": "5im3Ar56XJV6nYBAy4z6f-dVqd3UKSHkVS9NQKW08-Y",
  "client_secret": "...",
  "vapid_key": "..."
}

Here's a pruned version of the instance info Bridgy got from holonet.social at that time:

{
  "uri": "holonet.social",
  "title": "Holonet Social",
  "short_description": "Holonet Social is a galactic hub where beings gather to connect, share ideas, and engage in exciting conversations.",
  "description": "",
  "email": "justin@nojedi.org",
  "version": "4.1.7",
  "urls": {"streaming_api": "wss://holonet.social"},
  "stats": {
    "user_count": 1,
    "status_count": 135,
    "domain_count": 7488
  },
  "languages": ["en"],
  "registrations": false,
  "approval_required": false,
  "invites_enabled": false,
  "configuration": {"..."},
  "contact_account": {
    "id": "110639374792475459",
    "username": "justin",
    "acct": "justin",
    "..."
 },
  "rules": ["..."]
}

[snarfed]

Did you maybe move the instance to a new host since Sept 15? Or recreate it, or do anything else that might have wiped the registered OAuth apps?

In any case, it's easy to wipe this OAuth app from Bridgy's records and have it create a new one. I am still curious what happened though.

[hugogameiro]

@snarfed holonet.social is hosted with me on Masto.host and @justincox forward me a link to this thread to see if I could help.

So, the instance has not moved server since Sept 15 and I can't think of a reason why this oAuth app would be deleted. Doing a query in the oauth_applications database table, I don't see that record (or any other from Bridgy) but I see other oAuth apps older than Sept 15. It's really strange.

Also, I did a Bridgy test earlier today on a test Mastodon server on Masto.host and it worked fine. So, there I don't think there is any incompatibility with Masto.host. Somehow that record just got deleted.

Unfortunately I don't have a log that goes back from Sept 15 that I could see all that happened and why that record was deleted but do let me know if there is something I can look for on my end.

[snarfed]

Thank you for looking @hugogameiro! Definitely an odd mystery.

For now, I've archived this OAuth app on Bridgy's end and had it generate a new one, client id nObmt8su2u3MgC94w5R-58R7UEqO6fqjczD_dEVIAT0. @justincox feel free to try again!

[hugogameiro]

I had another report from a different instance with a similar problem but when authenticating with Buffer. Still had no response from Buffer regarding that. It does start to feel that either Mastodon is automatically cleaning/deleting some oauth_applications from the database, or Mastodon is failing to save them or there is something else going on that I still couldn't find a pattern/answer for.

[justincox]

@snarfed That time it worked! Thank you. I'll leave the greater discussion about what is causing the issue to you and @hugogameiro

[rg-wood]

Still doesn't seem to be working for me.

[snarfed]

@rg-wood yeah that fix was only for holonet.social, not your instance toot.io. I wonder if we're seeing the same problem there though. Bridgy created the OAuth app below on toot.io at 2023-04-22 10:29:09 UTC with client id IynWaVvErkoTYf2lDByy5sSH1_m4Bx1Uipr_a3tuLi8. Could you check with your instance's admin to see if that app is missing on their end?

{
  "id": "16890",
  "name": "Bridgy",
  "website": "https://brid.gy/",
  "redirect_uri": "https://brid.gy/micropub-token/mastodon/finish\nhttps://brid.gy/publish/mastodon/finish\nhttps://brid.gy/mastodon/delete/finish\nhttps://brid.gy/delete/finish\nhttps://brid.gy/mastodon/callback",
  "client_id": "IynWaVvErkoTYf2lDByy5sSH1_m4Bx1Uipr_a3tuLi8",
  "client_secret": "...",
  "vapid_key": "..."
}

[wiegelmann]

I have access to the toot.io instance database and there is no app registered from Bridgy at 2023-04-22. If you need further debugging help, just let me know.

[snarfed]

Thank you for looking @wiegelmann! So odd. I'm very curious why Mastodon instances seem to be losing OAuth apps.

In the meantime, @rg-wood I've archived this one on Bridgy's end too, feel free to try again.

[hugogameiro]

I just opened a ticket on GitHub with all the information I could gather: https://github.com/mastodon/mastodon/issues/27740 Feel free to add any more information there.

[snarfed]

Conclusion in https://github.com/mastodon/mastodon/issues/27740 is to periodically call /api/v1/apps/verify_credentials to confirm that an app is still valid. Not ideal, but ok.

[snarfed]

Deployed in snarfed/oauth-dropins@c127c287ad6841616e4f598185a03fb2f48a34df

[snarfed]

Reopening due to #1644. The original fix here in https://github.com/snarfed/oauth-dropins/commit/c127c287ad6841616e4f598185a03fb2f48a34df worked for OAuth clients (apps) that we never generated an access token for, but not for clients that we generated a token for, but then that user revoked the token from inside Mastodon, and then Mastodon garbage collected that client.

The fix for that is probably to delete an account's MastodonAuth entity when we get a 401 for it and we raise DisableSource. This will fix it for accounts with backfeed enabled, since we poll those regularly, but it won't fix it for accounts with only publish enabled that don't publish via Bridgy very often. 😐

[snarfed]

From https://github.com/mastodon/mastodon/issues/27740#issuecomment-1891241015:

I ran into another edge case with this garbage collection recently. We have a small fraction of users who make API calls infrequently. We hit a case recently where we had just one user on a given instance, they revoked our app's access inside Mastodon, which then garbage collected the OAuth client, and then a new user on that same instance tried to sign up. We hadn't yet made another API call with original user's token, so we hadn't yet gotten a 401 and learned the client had been garbage collected.

When there's just one outstanding token for a given client, it's easy to call verify_credentials first and check it. If there are n outstanding tokens, though, calling verify_credentials on all of them would be unfortunate, at best.

[snarfed]

OK, I think this is fixed going forward now, a different way.