Identity provider and SSO for Kupolo.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Adrian Malacoda 0f3770157d use correct title for error page too 9 months ago
integration-tests add readme 1 year ago
lua add an example lua module for user store 1 year ago
res use correct title for error page too 9 months ago
src use correct title for error page too 9 months ago
.gitignore add gitignore 1 year ago
Cargo.lock Rename who_server -> kupolo 9 months ago
Cargo.toml Rename who_server -> kupolo 9 months ago
LICENSE Add LICENSE. 1 year ago Add LICENSE. 1 year ago add config parsing to roadmap (phase I) 2 years ago remove javascript file, who server will try to avoid javascript as long as possible 1 year ago
package.json Remove browserify since we don't have any javascript (yet) 9 months ago
rust-toolchain add rust-toolchain file for nightly 1 year ago
who-server-2.toml add an example lua module for user store 1 year ago
who-server.toml make url key in config optional, since it can be determined from request 1 year ago

Who server

This is the Who identification/authentication service and identity provider. It implements the Project Badger authentication protocol (OpenID Connect with Discovery and Self-Registration) and provides a means to authenticate local and remote users, which can be used in any number of applications. Who server will be deployed to the flagship Project Badger server at, and can optionally be used by other servers participating in Project Badger.


The Who server uses the Who library to identify users by an identifier such as a http[s]:// or acct: URI. The Who server can return zero or more user accounts associated with that identifier.


Users identified by the Who server may broadly grouped into internal or external users. When the user enters their identifier into the Who server, if there are multiple accounts discovered, they may be prompted to choose one to authenticate with. If there is only one, the Who server may automatically proceed with the flow for that account (e.g. OAuth redirect, password prompt).

Internal or Local users

Who server can be connected to a local user account store (e.g. LDAP, or a table in a database) and provide a password login, with optional two-factor auth support.

If the Who server is connected to a local user account store, registration can be enabled. Who can send events to interested applications when a user is registered.

External or Remote users

Who server can authenticate users of external servers, such as OpenID, OpenID Connect, certain proprietary OAuth services, and even other Who servers. Note that, strictly speaking, the Who server only wants to authenticate such users; it does not need to be authorized to access the user’s data on that external service. Therefore, the Who server should only be granted only the scopes necessary to authenticate users.


An application using the Who server for authentication can integrate using protocols such as OAuth 2/OpenID Connect, CAS, SAML, IndieAuth, or some other protocol. Such applications might not necessarily be hosted on the same server as the Who service.


GNU Affero GPL v3