|Adrian Malacoda 0f3770157d||1 year ago|
|integration-tests||2 years ago|
|lua||2 years ago|
|res||1 year ago|
|src||1 year ago|
|.gitignore||2 years ago|
|Cargo.lock||1 year ago|
|Cargo.toml||1 year ago|
|LICENSE||2 years ago|
|README.md||2 years ago|
|ROADMAP.md||3 years ago|
|build.rs||2 years ago|
|package.json||1 year ago|
|rust-toolchain||2 years ago|
|who-server-2.toml||2 years ago|
|who-server.toml||2 years ago|
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 monarch-pass.net, 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).
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.
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.