API-Based Sign-Up Rules/Policy

So, with past dramas, I figured this might be a question to raise and thrash out so we can have a sensible discussion about how to approach in a way which will eliminate drama or potential problems.

I have wanted to, for a while, simplify the user sign-up experience to tools I run such as FFScouter. Requiring them to visit the website and manually copy/paste keys is a bit of a pain and prone to errors, and just doesn't make for a great user experience. So, the idea of an automatic/API-based sign-up to integrate with existing services has been in my view for a bit. But I am wary of past misunderstandings given I sometimes don't appreciate/understand how non-tech folk might comprehend the processes or I may not understand their assumptions.

The rules already have a section for integrations, seen below:

"When integrating your service with another service (opt-in), make sure there's at least a link to ToS of the service you're allowing the user to integrate with.

When integrating your service with another service (automatically), your ToS need to cover the usage of the service you're integrating with."

So, if my understanding is right, a third party script is able (if I built it) to opt-in or "share" an existing API key to another service. I think that from a rule perspective is already clear-cut.

Where I have more concerns, is tracing the origins of this in various ways and accountability. I label all FFScouter requests to the Torn API which originate from a single static IP, and logs are kept for a while to help trace the origin of signups. However, this is no guarantee somebody will not assert that their API key was misused as I have no control over third party scripts or services to ensure they are ToS compliant, if I enabled an API-based signup mechanism.

Open to all ideas on what mechanisms we could look at to enable a more seamless sign-up experience between services, without also opening up to the risk of abuse. I think the actual number of abuses are quite low and niche in this scenario, since it assumes somebody must already have an API key to misuse, but scope for misunderstanding is wider where a script out of our control might present the integration in an undesirable way.

Is this actually a substantial issue? I haven’t seen this in Tornium’s authentication logs much beyond users pasting garbage strings and users failing to lack the capacity to read error messages (for stuff like wrong access level).

You could use OAuth instead of API keys on userscripts. However that comes with more complexity, with on Tornium, users seem to have trouble with the complexity of short-lived access tokens and developers have issues implementing the OAuth spec properly.

OAuth might work, but FFScouter needs the API to make things workable, like the attack log gathering and battle stats to give the FF estimates etc, so it would fundamentally need the key, and it does seem like a lot of overheads versus a simple API spec to post a key as a "signup".

I would hope simplicity would reign for API key sharing really.

Yeah, you’d still need to sign in on the FFScouter website. But it kinda reduces the complexity of ensuring users properly paste the keys into both the website and userscript while preventing the unlikely malicious actor from co-opting API keys. It is a lot of additional complexity though that may not be worth it for you.

Yeah, I mean that is where my concerns really lay. I think somebody using a stolen/misused key of somebody else is somewhat moot, as it doesn't give them access to information that isn't already public using their own key, so the scope for misuse is arguably low in my case. But, signing up a third party to let me grab that data is the issue really, proving some kind of informed consent of the matter.

I can easily add a field to store some signup data such as IP, user agents and so forth to provide to admins if this was ever an issue, but that is more a method to catch than prevent.

Wonder if an admin could chime in, perhaps a case-by-case approach would work based on the service and what data would be shared/exposed and for what purpose, but I already find it quite difficult to get clarifications as it is :(

Ideas from a user's perspective:

Add button toggles for each existing and new feature with a Save Settings button in case of accidentally something on. Users must press Save Settings to save their toggle selections.

Upon implementing this, have every toggle button set to "do not use", except FF Scouter itself (main functionality) which is required ON toggle to use your website. Alternatively include FF Scouter in the optional toggles and when you implement toggles turn it off by default (users must log in to the website to actively select ON the toggle).

Options to have different or same API keys stored for each feature.

Well this is the crux of it, it would be nice to be able to have a shiny button in any script saying "Enable FFScouter" - and that is all the user has to do, rather than need them to log into the website first, and it then checks the API key being shared is suitable for use and if so, everything is seamless and automatic. People shouldn't ideally need to visit except if they want to go into the ToS in more detail.

Okay so if a user has an account already (has used an API key to log in via the script or the website), using any API key will log them into their account, where FF Scouter will be enabled by default.

In the user settings (click to expand):

Have a section where all API keys logged into the database are shown, maybe first 4 digits only in case it isn't the actual user. Sorted by last used API key on top.

Each API key can be manually trashed from the database from this page. Trashing a key is instant, and does not require setting to be saved.

When the last API is deleted, the user is logged out of the page and redirected to the log in page.

Another section with a toggle selector for existing and new features with a pop out link to the TOS or Description page (which links to its TOS) for each feature.

FF Scouter is toggled ON by default. It cannot be toggled off from this page, with a note explaining this. The key used for FF Scouter cannot be changed from here, it must be changed via the script used to access the database. But the first four digits are to be shown as for all other features.

Each feature has a spot for a new API key to be inserted, but the API key is pre filled upon toggle ON with the last used API key (first 4 letters only are shown).

User can manually paste a different API key into each section.

The page has a Save Settings button. No settings are saved until Save Settings button is pressed.

I have been testing an OpenID Connect based flow for my own tools. It uses an identity provider (Authentik) to handle login, registration and consent. This removes the need for users to copy and paste API keys across services or share them with scripts they do not fully understand.

The current Torn API key model puts almost all the risk on users. They hold a long term key that grants broad access. They are expected to decide where it goes, how it is stored, and which parts are safe to share. Most users do not think in scopes or understand trust boundaries. This makes mistakes easy to make, and hard to prove or unwind when something goes wrong.

If Torn moved to an OAuth2 or OIDC model with registered third party applications, several gains appear:

For users:

• Clear consent screens showing which app is asking for what.
• No handing over full API keys. Instead, scoped tokens with limited access.
• A place in Torn settings where they can revoke access at any time.
• Less fear that "someone has my key forever".

For Torn:

• Tighter control over who builds what. Apps would be registered and traceable.
• Better audit logs. Torn would know which app accessed which endpoint with which permission.
• Reduced support headaches when users claim misuse or misunderstanding.
• Greater user trust, which is key to long term platform health.

For developers:

• Cleaner integration. Redirect user to Torn for login and authorisation, get back a token with the right scopes.
• No need to handle raw API keys or ask users to paste secrets into random tools.
• Less responsibility for proving consent, since the platform handles it.

This is normal practice for every platform that handles sensitive data. It improves privacy, reduces exposure, and makes consent visible, traceable and revocable. It does not reduce developer freedom, it introduces platform-level trust.

The problem we keep circling is not integrations or sign-up flows. It is the lack of a proper identity and consent framework. OAuth2 and OIDC solve that problem.

If I had enough motivation and if I even thought for a second TornHQ would listen, I might be campaigning harder for it.

Given that Torn doesn’t want to add a state parameter or PKCE to their Discord OAuth client (and the former is now required in the newer RFCs) to prevent phishing and other stuff, I wouldn’t expect much from them building an OAuth provider in the first place.

Honestly, now you see why my motivation to campaign for it isn't as focussed.

Frankly, the whole impression I get for the development effort for APIv2 etc is that they just don't care. API is a second-class. It's just "not interesting" and it "does the job".

Frankly, these are genuinely abhorrent approaches to take, but as an API consumer, I have little to no say.

Ched/Splent et al: your approach to things sucks more than discounted ball gags at a suburban swingers’ raffle.

Just out of curiosity - how many tools do you think would actually use oidc over current api login approach? It requires a lot more setup and maintenance from the developers, most of which are building quick weekend projects. How many services / tools can you name that would actually benefit / require a log in? Yata, tornstats, ffscouter, weaver bazaar tool, torn report, tornium. What else? And i mean services with an actually significant user base. With that in mind, do you think it justifies the effort required from Torn developers to implement it from their end?

I'm not against implementing oidc, i just don't see the justification for the effort required to do so. There are way too few tools that are widely used, or developers that would actually bother to implement oidc over the api registration method imo.

Quick tooling is still doable since you could just implement API keys as a plain auth token or maybe even a service account of the user principle - with JWT or bearer token as is currently the case. JWT would be the preference since the API wouldn't need to then authenticate the request... Just validate the signature and scoping included in the token.

In my case I need the OIDC because of the nature of the thing that I'm building and the APIs and network protocols I'm exposing.

This would also work towards things like Faction keys given enough thought. Although I've not spent any significant time thinking that through, but my initial thoughts would be that each faction would be modelled as a first-class principle or service account within the OIDC framework. That would allow faction leadership or those granted faction admin scopes would be allowed to impersonate the faction principle.

I think you missed my point there. 99% of people developing stuff for torn are self-learned amateur developers who have probably never even heard of oidc, let alone validating jwt tokens. Do you think not having proper oidc is stopping anyone from developing their tools?

I think your second paragraph highlights my point - in MY case I need oidc. Exactly. YOU need it and maybe 5 other developers at most. Do you feel like that warrants directing Torn dev focus towards implementing OIDC at this point in time? Look at the suggestions regarding oidc - they get under 10 upvotes total, some probably coming from friends on request.

Having proper auth mechanisms is nice and all, but it requires extra development and maintenance - you have to remember this is primarily a game, the community dev segment is just a small part of it. You are treating it like it is a proper service provider and the community devs make up the majority of the userbase.

I didn't miss your point, but you might have missed mine (or perhaps I wasn't quite clear enough).

The simple API token thing wouldn't change for weekend API hacking hacking and devs looking to do things simply. OIDC does not remove the API Token system. You can still create bearer tokens or API keys. They would just be authenticated by OIDC layer... In fact, the JWT approach wouldn't even need to be authenticated. The validity of the JWT is bound to its signature, and you can bundle all the necessary scoping, expiration, subject access into the token. As long as the signature is valid, the JWT can stand alone.

...yes, I do feel that updating the auth system in Torn is warranted, but then I am a systems engineer in my dayjob, so my answer will always be biased towards progressive development where long-term benefits will outweigh the short-term pain.

I don't deny it would be some work to get something built, but the fact is: Torn already has half of the work done. It's already using an implementation of OAUTH in the form of Google and Apple logins. It clearly wouldn't be a massive stretch to stand up an OIDC service on auth.torn.com, import all the current credentials and slowly transition auth to the OIDC platforms. Torn already accepts scoped tokens for auth.

Your point about "my" use case is moot because while I have mentioned it before, and raised it as part of other threads, I did initially respond above with:

If I had enough motivation and if I even thought for a second TornHQ would listen, I might be campaigning harder for it.

That's not to say I'm not going to keep dropping OIDC into threads discussing API Auth though.

As an aside, and part of the old-guard, perhaps you might want to review your own bias, too.

I would argue that the community dev segment is not as small a part of it as you claim. TornPDA, TornStats, Torn.Report, Torn Engine, YATA, Tornium, FFScouter, the myriad of user scripts... Show me one semi-serious player on this platform that does not use any of the third-party scripts or quality of life enhancements or scripts to make the game playable. Moreso the user-scripts.

Since I started with Torn API stuff, I've gotten nothing but "this is how it's always been" or "ched isn't interested" or "no-one would use it"... and frankly that attitude is backwards and lumps us with all the levels of technical debt that Splent is currently fighting against.

We now have an OpenAPI spec because of that work from Splent🥰. It takes me all of about 120 seconds to completely update my API clients, run my test suites, commit, rebuild docker containers and all because of that OpenAPI spec. I could probably throw it into CI and get that time down further. I cannot imagine how easy it is for others now that we have that with the SwaggerUI. I would argue that the addition of swagger and openAPI has possibly helped the dev community more than you imagine.

I would not personally be so quick to discount and dismiss progressive thinking for the sake of "it's just a small part" of a community.

Ok, well going off topic a touch, but my 2c on the issue of OAuth2 etc.

It takes time away from developing other features. That is my major objection.

I have made other suggestions about requiring app developers to label requests etc in the past and a potential system to whitelist/enrich IP information to map it to Torn accounts for central apps (ie non-userscripts). That would eliminate many common issues.

Userscripts are a huge part of Torn's community nowadays and I don't see them working with OAuth really? 

It's not too bad. You'd need to make it a public client and regenerate the token frequently to avoid other userscripts from stealing the token... then again userscripts that use API keys have the same problem and no one mitigates it. Largest problem is that many people don't understand them and it would cause a lot of confusion until people got used to it.

A full OAuth/OIDC is probably only really relevant to developers who have written applications that need access to API data for accounts where proof of account ownership is important. I'm not discounting user scripts, but they could easily be swapped over to use a JWT issued by the OIDC platform. Again, don't need to use an external app to verify the key, just verify the signature... This could also use the current API token system too...

There are two areas I feel where the current API token auth falls down:

1. Identity - proving that the person presenting the API key owns the account related to the API key
2. Reauthorisation and consent - checking to make sure the we still have the users consent to use the API key

There are means and ways around both of these, but they're my responsibility as the app developer... and not baked into Torn.

you could make them send you a dollar from their account to your account with a 2fa code generated by your site as the message, then have your api key check your money recieved log to pull out the message to confirm it?