src | ||
.editorconfig | ||
.env | ||
.gitignore | ||
Cargo.lock | ||
Cargo.toml | ||
clippy.toml | ||
config.toml.example | ||
deny.toml | ||
LICENSE.txt | ||
README.md |
factoriauth - an unofficial Factorio authentication server
Let's say you and your friends are
- on an oil rig,
- in space, or
- in the far future,
and you want to host a Factorio server. Because you don't have an internet connection (or the
official authentication servers don't exist anymore), your only option is to disable
require_user_verification
in the server config - but this allows anyone to connect as any user,
which is no good, especially for PvP scenarios! Wouldn't it be great if you could set up your own
authentication server?
factoriauth is exactly that. It allows clients to log in as custom users provided by one of several authentication backends (e.g. LDAP or a passwd-style file), and allows servers to validate that these custom users are properly authenticated.
Roadmap
Complete
- server padlock generation (
POST /generate-server-padlock-2
) user_server_key
generation (POST /generate-user-server-key-2
)- user token generation and storage (
POST /api-login
) - LDAP authentication backend
- server padlock proxying (to allow e.g. factorio.com users to join servers using a custom auth server)
Planned
- more authentication backends: user file, PAM(?)
Unplanned
Setup
Configuring factoriauth
Copy config.toml.example
to config.toml
and adjust as necessary.
Padlock source
There are two possible sources for server padlock: either generated standalone by factoriauth for completely self-contained setups, or through a padlock proxy.
For the standalone deployment, padlock.secret
needs to be a hex-encoded binary string of at least
32 bytes - either generate your own, or attempt to start factoriauth once and copy the freshly
generated secret from the error message.
To use the padlock proxy, padlock.proxy
needs to be set to the base URL of another factorio auth
server, e.g. https://auth.factorio.com
. Server padlocks will be obtained from this auth server,
allowing users from both factoriauth and the upstream auth server to join the game server.
LDAP authentication backend notes
Factoriauth first binds anonymously to the specified LDAP server in order to look up the login
user's DN under search-base
, thus permitting e.g. login via email. The LDAP server
must be configured to allow this in order for Factoriauth to work correctly.
Configuring clients/servers
To use the auth server, the following snippet needs to be added to the clients' and servers'
config.ini
, replacing the URL of the server as appropriate:
[servers]
auth-server=https://my-auth-server.example/
NOTE: If a client isn't entirely offline, you also need to override the updater server to an invalid/unreachable address, otherwise the client will contact it with an invalid token on startup and prompt for a re-login:
[servers]
updater-server=http://invalid.example
Running factoriauth
Either use cargo install --path .
and follow its instructions for how to update $PATH
, then run
factoriauth run
, or run the program straight from the repository: cargo run -- run
.