Auth key system to interact with third-party sites. - Make kiwi projects safe again.

[P R O X Y]

Okay, this is probably a fucking stupid idea but I'll bite on it.

Is there a way within the forum software, or even just outside of that to make API keys for users. The API keys are not to actually interact with KF, but external projects.

For example, I want to setup a file host that is only accessible to KF users, so they authenticate via an API key supplied from KF. The idea would be that after a set period of time, or activity, someone can have an API key and use it to sign up to external services from other KF members.

This would honestly make setting up services like file uploads, archives, etc much easier if it's known that its only other members using it. I would feel much better setting up an archive for example that is publicly accessible but only people who could use the tool would be other forum members.

I'm not sure if this is a stupid idea, I'm willing to donate to get it implemented if that's what null daddy needs. But I do think it would push us forward for community safe projects without third party cowards ruining everything.

 

[libRT]

There would need to be some verification between KF and the API services. Unless you plan on DMing people API keys and they have to set them up themselves, or on some page on the service.

I wouldn't use it though, having a unique API key per user is another identifier, and if the services are for KF users only, its just more targets.

 

[Milton Luther Keynes]

The OAuth/OpenID Connect authorization code flow is a technology that is designed for use cases like this. It's the technology that underpins "Log in with Google/Facebook/whatever." No API keys, though: instead, the external app sends the user to a login page on the Farms with a specially-crafted link; they enter their username and password and the login page redirects them back to the external app with a short-lived authorization code that the app backend sends to the Farms' OIDC server. In exchange the server sends back a signed JSON Web Token that says "This person successfully logged in. You can consider them authenticated until such-and-such a time." The public key for verifying the token is exposed by the OIDC server on a standard endpoint so the external app can satisfy itself that the token was really issued by the Farms, so at that point it can consider the user authenticated.

 

[Grub]

For example, I want to setup a file host that is only accessible to KF users, so they authenticate via an API key supplied from KF. The idea would be that after a set period of time, or activity, someone can have an API key and use it to sign up to external services from other KF members.

I don't trust anyone on kf enough to use or rely on external services created by them. Sounds like another @byuu Minecraft mod adventure waiting to happen.

This would honestly make setting up services like file uploads, archives, etc much easier if it's known that its only other members using it. I would feel much better setting up an archive for example that is publicly accessible but only people who could use the tool would be other forum members.

But why? What benefits would using an archive or upload service that can only be used by forum member have over literally any other upload service. As it is, when you upload pictures or videos to kiwifarms it is being hosted directly on the site itself and you need to be a member to upload so why would I want to use an external service for that? Also, as far as I know, null prefers if files are hosted on the farms itself rather than third party providers.

 

[Null]

You're describing OAuth. XF does have OAuth but it's for other 3rd parties. I've discussed this with @CrunkLord420 before, and his opinion is that OAuth for shit like that is cancer, though I do agree that it would be handy. It would be a cool feature for Rustforo.

 

[CrunkLord420]

I think OAuth is a "dark pattern" and risking centralization of access to third parties like Google. There are services out there that actually do this, you literally cannot just register an account, you must do this through a third-party megacorp. I don't like it, it's weird and makes my conspiracy alarms go off. It feels like a giant attack surface waiting to get exploited. It seems like a privacy risk. The whole thing smells bad. You don't need this, it just makes things unnecessarily complicated. Just register an account like a normal person. Use a password manager.

 

[P R O X Y]

I'm familiar with OAuth, took the inspiration from a skid forum who gives API keys to upgraded users that can be used across products/services by other community members. API keys can be generic enough, I wasn't sure what fully OAuth might entail when it comes to setting it up yourself but good to know.

To give context, I understand multiple points being made here. Centralization, risk of decreased privacy, and I guess just other forum members being assholes.

My idea was more of an idea to push the idea of developing services by members for members. Which I know can be abused, but I think the struggles I see the forum have is that how many people are actively building? Maybe I am alone in this thought, but I like the idea of a service I make that while the end results are completely public, the contributions are from other forum memebrs. If I set up an archive, and it's associated with my current username/KF membership .. then it will get targeted by people who don't know what gentials they want for the day.

If you restrict the OAuth based auth to "True & Honest" only, then at least the people looking to sabotage our community are financially supporting it.

If you want to run down the rabbit hole of centralization, you are correct that there is some risk for that. But there are far more important aspects of decentralization for the community, like additonal projects, rather than authentication. Someone can still very well target our forum members with or without OAuth, but would you rather them auth VIA OAuth or through something like email + username in which you hope they didn't fuck up and reuse one or the other?

As for attack surface, I can see where maybe depending on what the OAuth leaks about the user this can be used to target users obviously. Again, I'll look through documentation and see what risk there fully is but I'm sure there is a way to pass minimal information via OAuth that while other information like IP, Browser, etc might still be tracked .. can it be tracked back to a specific user?

I hope I am making these clear. I do think it is of value, and would encourage more community projects. I do understand there are risks with it however.

 

[ᚠᚢᚦᚩᚱᚳ]

I'd actually like to see the XenForo API enabled for users, having spent most of the day rewriting a Tampermonkey script that basically shows where people post and counts how often they say "nigger" and "tranny." I'm aware of their retarded implementation about how it's this crazy feature that only admins can use because apparently passwords don't already exist. Speaking of authentication more generally, when are we getting WebAuthn for logins? It's a very simple protocol to implement, and the TOTP option hasn't been generating QR codes since I joined.