# Service authentication and user access

Source: https://govform.com/resources/documentation/article/21-02-service-authentication-and-user-access
Topic: Service Settings

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

1.  Test a new person with the expected identity provider.
2.  Test a person who should be denied access.
3.  Test sign-out, browser back navigation and return to the service.
4.  Test session warning and expiry while completing a realistic page.
5.  Test group sharing with the minimum and maximum intended permissions.
6.  Test saved-draft resume, restart and any task-list or review route.

## Sign-in email format

For Govform passwordless email, choose Use library setting, **Basic text** (the full link) or **Standard** (branding and a Sign in button). `authSignInEmailFormat` is empty/unset for inheritance, `basicText` or `standard`. New services start with Standard; existing settings are preserved. GOV.UK Notify uses its configured template.

Library and service configuration must be published to the environment being tested. These email appearance choices do not change the identity provider, grant access or verify an email delivery.

## Related guides

-   [Service identity, lifecycle and administration](<https://govform.com/resources/documentation/article/21-01-service-identity-lifecycle-and-administration>)
-   [Service content, branding and languages](<https://govform.com/resources/documentation/article/21-03-service-content-branding-and-languages>)
-   [Service navigation, review and PDFs](<https://govform.com/resources/documentation/article/21-04-service-navigation-review-and-pdfs>)
-   [Test, deploy and maintain a service](<https://govform.com/resources/documentation/article/13-test-deploy-and-maintain-a-service>)