Service authentication and user access
Authentication settings decide who can enter a service, how long they remain signed in, and whether people in the same group can work with the same journey. Configure them from the service’s Settings area only after defining the intended audience and access model. An authentication change can make a working service unavailable, so test it in QA with the real user types.
Choose the access model
| Need | Suitable approach | Check before release |
|---|---|---|
| Anyone can begin without signing in | Enable Anonymous mode. | No sensitive information or personal follow-up relies on identity. |
| People sign in with the platform’s passwordless method | Use the default identity provider. | Sign-in, return to service and sign-out all work. |
| The organisation uses a managed identity provider | Use OpenID Connect or Cognito where configured. | Claims, group mapping, sign-out and access-denied behaviour are correct. |
| People in a defined group should share a journey | Enable Group sharing and select the minimum appropriate access level. | People outside the group cannot view or edit it. |
Do not turn on anonymous access simply to bypass a sign-in problem. It changes the service’s security model and can affect saved drafts, sharing, correspondence and review.
Configure a sign-in experience that explains itself
The service can override the library’s Sign-in page title, Sign-in page content and authentication application name. Use a clear title such as Sign in to continue your application. The supporting content should tell people why they need to sign in, what account to use, what will happen after sign-in and where to get help.
The sign-in content supports formatted text and dynamic values where configured. Keep it simple and test it with a screen reader and keyboard. Do not include client secrets, provider configuration, access tokens or sensitive account information in page content.
For external identity providers, a custom sign-in page can be configured where appropriate. Treat it as part of the access journey: it must have a clear service name, correct return route, error handling and accessible support information.
flowchart LR
A["Person opens the service"] --> B{"Anonymous access?"}
B -->|"Yes"| C["Start the journey"]
B -->|"No"| D["Show sign-in page"]
D --> E["Identity provider verifies access"]
E --> F{"Authorised?"}
F -->|"Yes"| C
F -->|"No"| G["Explain the next step or support route"]Set session timeout deliberately
The Session timeout setting can override the library value for a single service. The Timeout warning display duration controls how long the person sees a warning before the session ends. Balance data protection with the time people need to find evidence, discuss answers or complete a long task.
Use a clear warning that tells people whether they can extend their session and what happens to unsaved information. Test the warning and expiry during a realistic journey, including a task list, file upload and Check your answers page if the service uses them.
Group sharing is an access-control decision
When Group sharing is enabled, people with the same configured group ID can share access to a journey. Configure the Group ID property to match the correct identity attribute, then choose the minimum Group sharing access level:
| Access level | Capability |
|---|---|
| Read | View without editing. |
| Write | View and edit. |
| Full | Manage, edit and view. |
Use sharing only where the business process calls for collaborative work. Test with separate accounts in the same group and a different group. Confirm the visibility of personal data, uploaded files, review state and any withdrawal or cancellation action.
Decide how signed-in people resume drafts
The Resume draft form behaviour decides what happens where a person returns to an existing draft: prompt them to choose, resume automatically, or delete the draft and begin again. The most direct option is not always the safest. Prompting suits journeys where circumstances may have changed; automatic resume suits a clearly personal, short-lived journey; delete and restart should only be used when the loss of draft answers is expected and explained.
Task-list and review services have additional behaviour that can limit the available resume options. Always test the live User view behaviour for the exact service pattern.
Manage service users and sign-out
Service user configuration determines which Builder users have access and permissions. Apply least privilege: grant access only to people with a defined role, review it regularly and remove it when no longer needed. Use the normal library user-management process rather than sharing an account.
The End session / sign-out header link normally lets people end their session. Hiding it may be appropriate for a controlled kiosk-style experience, but can confuse people using a shared device. If it is hidden, make sure a safe alternative exit and session-expiry process exists.
Test an access matrix in QA
- Test a new person with the expected identity provider.
- Test a person who should be denied access.
- Test sign-out, browser back navigation and return to the service.
- Test session warning and expiry while completing a realistic page.
- Test group sharing with the minimum and maximum intended permissions.
- Test saved-draft resume, restart and any task-list or review route.