Sign-in options and single sign-on

Site administrators choose how people sign in under Administration › Settings › Sign-in. The sign-in page then shows a button for each way that is switched on, and the user name and password form when passwords are on.

Changes apply at the next sign-in; the site doesn't need a restart.

Who gets in

A provider proves who someone is. DocView then decides whether they get in:

1. Someone already linked to a DocView account with this provider signs straight in.
2. Someone with a DocView account of the same e-mail address signs in, and the provider is linked to their account. DocView only trusts an address the provider has confirmed. For Microsoft that is the person's sign-in name, never the e-mail field, which anyone can fill in within their own tenant.
3. Someone from a listed e-mail domain gets an account on their first sign-in, in the organisation and with the role you choose for that provider.
4. Anyone else is told there's no account for them and to ask their administrator.

To invite one person, create their user under Users & security › Users with their e-mail address. They can then sign in with any provider that confirms that address.

Microsoft

1. In the Azure portal, open Microsoft Entra ID › App registrations › New registration.
2. Name it DocView Capture. Under Redirect URI, choose Web and paste the redirect URI shown on the Sign-in page, for example https://capture.example.com/signin-microsoft.
3. Copy the Application (client) ID into DocView.
4. Under Certificates & secrets, create a client secret and paste its value into DocView. Note when it expires.
5. Under Who can sign in, enter your tenant ID (or your domain) to allow only your organisation, or organizations for any work or school account.
6. Select Test, switch the provider on, and Save.

Google

1. In Google Cloud console, open APIs & Services › Credentials › Create credentials › OAuth client ID, type Web application.
2. Add the redirect URI from the Sign-in page, for example https://capture.example.com/signin-google.
3. Paste the client ID and client secret into DocView, switch it on and Save.

Apple

Sign in with Apple needs a paid Apple Developer account.

1. Under Certificates, Identifiers & Profiles › Identifiers, create a Services ID. Enable Sign in with Apple, add your site's domain, and use the redirect URI from the Sign-in page as the return URL.
2. Under Keys, create a key with Sign in with Apple and download the AuthKey_….p8 file. Apple lets you download it once only.
3. In DocView, enter the Services ID, your Team ID, the Key ID, and paste the whole content of the .p8 file. DocView keeps it encrypted and uses it to sign each request to Apple.

People can choose to hide their e-mail address from you. Apple then gives a private relay address (…@privaterelay.appleid.com), which won't match an existing account. Invite them with that address, or let them use another provider.

Any OpenID Connect provider

Register DocView as a confidential web client using the authorisation code flow, with the redirect URI from the Sign-in page. In DocView, enter the provider's address (its issuer, for example https://login.example.com/realms/staff), the client ID and the client secret. Test reads the provider's sign-in details to check the address.

Switching passwords off

You can switch DocView passwords off once everyone signs in with Windows or a provider. Site administrators can still sign in with a password at /account/login?local=1, so a problem with a provider never locks everyone out. Keep at least one way to sign in switched on.

Security notes

• Client secrets and the Apple key are stored encrypted and never shown again. Leave the box empty to keep the stored value.
• Each sign-in is recorded under Users & security › Sign-in history with the provider used.
• Sessions, idle time-outs and IP rules apply to every way of signing in.