Mastodon backend: advice on how best to do it

[stuartlangridge]

I'm looking at building a Mastodon backend, to be used in Django. It's basically standard OAuth, but with a twist: because there are many Mastodon servers rather than just one, you don't pre-register an app with the single server and then store the client key/client secret in settings. Instead, the user supplies the name of their Mastodon server and you use an API call to dynamically register an app on that Mastodon server to get a client key/secret specific to that server. After that it's the standard OAuth process. (https://shkspr.mobi/blog/2024/12/creating-a-generic-log-in-with-mastodon-service/ has the detail.)

What I'm not sure about is how best to do this in the python-social-auth environment, so I'm looking for some advice or suggestions from the experts :-) There are three issues:

1. how does the Mastodon backend find out which server it should use?

My plan here is to make this the app developer's problem: they can ask the user for their Mastodon server and then link to {% url 'social:begin' 'mastodon' %}?mastodon_server=example.com for the "Sign in with Mastodon" link; the MastodonOAuth2 class can then pick that link off the end of the URL by looking at self.strategy.request_get("mastodon_server"). That is: this isn't our problem in python-social-auth, which seems fine.

2. at what point in the process is it best to make the API call to the mastodon server to register the app and get a client key/secret?

This can obviously be done at pretty much any point; in my current proof-of-concept, I do it in MastodonOAuth2.__init__, but perhaps there is a more appropriate place to do it?

3. where do we store the Mastodon server client key/secret?

This is the main question I don't know. Once we've registered an app with the Mastodon server and got a client key/secret, where do we store them? I don't want to store them on the user record in extra_data, because if a second user tries to log in via that same Mastodon server, we should reuse the key/secret we've already got; we should not register the app a second time and get a second key/secret! This suggests that, the first time someone signs in via a Mastodon server, we should register the app and store the client key/secret somewhere, and then the second time someone different does that, we should retrieve these existing key/secret details from the somewhere and re-use them. Where is this somewhere? Maybe the new MastodonOAuth2 plugin should register its own table and its own set of migrations? But is this even possible? And it would only be suitable for Django. Is there any way that a provider plugin can store data somewhere other than on a user object and retrieve it later?

If there are any other suggestions about good ways to do all this, I'm happy to listen!

[nijel]

I think that OpenID associations work similarly, so you might be able to reuse that storage. Look at OpenIdStore class for the implementation.