Wiki security is provided through the Passport.js. We can consider modifying the code to enable JWT based security for tranporters - github 
Configuring each OAuth provider requires two steps: i) regestering our wiki installation, as an app, with the OAuth provider, and ii) configuring Federated Wiki to use the shared secrets created.
Given the length of the parameters, we will be using a configuration file. This will need to be held somewhere safe, both so that others don't access it and also we don't loose it when updating the wiki software.
## Configuration File
For example, if we wanted to start in farm mode we might start with configuration file like that below. Replacing `ADMIN_USER_ID` with the identifier used to identify the Farm admin. This will vary depending on which OAuth service is used.
We can specify if we want the login dialog to use a secure connection, see adding TLS support for how to enable this. N.B. the interaction with the OAuth provider is always over a secure connection.
{ "farm": true, "admin": "ADMIN_USER_ID", "security_type": "passportjs", "security_useHttps": true }
## Wiki Domains
We need to add a section for each wiki domain, for this example we will use `example.wiki`.
"wikiDomains": { "example.wiki": { } }
## Register OAuth
Register your wiki installation with each of the OAuth providers you want to use. Remember, it is only wiki owners that need to sign-in, so you only need to register those you feel comfortable with using. Each OAuth provider handles authentication differently and has their own names for their authentication keys, so read the documentation carefully.
In each case the callback URL will be `http://[*hostname:port*]/auth/[*provider_name*]/callback`, or if we are using https `https://[*hostname:port*]/auth/[*provider-name*]/callback`.
Create an application with Twitter Application Management .
Example `Keys and Access Tokens` tab
Twitter recommends setting `Callback URL Locking`, this can be done on the settings screen, but also means that a separate application will need configuring for each wiki domain.
On the permissions tab, modify the access to `Read only`.
On the Keys and Access Tokens tab take a note of the `Consumer Key (API Key)` and `Comsumer Secret (API Secret)`
### Github
GitHub only allows the configuration a single authorization callback URL for each OAuth application, so you will been to create an OAuth application for each wiki domain.
Create an web application credentials with Credential page , also see creating web application credentials .
In the restrictions section on the "Client ID for Web application" page you can specify multiple `Authorized redirect URIs`. This means we can use a single configuration for multiple wiki domains, should we choose. We can also add the locations of our login dialog as the `Authorized Javascript origins` should we choose.
In the Credentials view take a note of the `Client ID`, and `Client secret`.
#### Wiki Configuration
Putting this all together gives us the configuration file for out wiki farm server:
{ "farm": true, "admin": "ADMIN USER ID", "security_type": "passportjs", "security_useHttps": true, "twitter_consumerKey": "CONSUMER_KEY", "twitter_comsumerSecret": "CONSUMER_SECRET", "wikiDomains": { "example.wiki": { "github_clientID": "CLIENT ID (1)", "github_clientSecret": "CLIENT_SECRET (1)" }, "example2.wiki": { "github_clientID": "CLIENT ID (2)", "github_clientSecret": "CLIENT_SECRET (2)" } } }
As long as we have not enabled `Callback URL Locking` in the twitter OAuth configuration the same settings can be used by both domains, which is done by configuring it outside of `wikiDomains`. In comparison GitHub only allows the configuration of a single callback URL, so we need a separate configuration for each wiki domain.
If you are not yet ready to use https, you will need to set `security_useHttps` to `false`.
## Starting Wiki Server
We need to pass the configuration file when we start wiki. This is done thus:
wiki --config /path/to/configfile.json