/
Setting Up Single Sign-On (SSO) for InTime

Setting Up Single Sign-On (SSO) for InTime

Owned by Stuart McKay
Last updated: Apr 25, 2025
5 min read

Contents

Introduction

RSM InTime supports Single Sign-On (SSO) configuration, enabling selected users or user groups to authenticate using their identity provider credentials.

 While InTime is compatible with various providers, Microsoft Azure is the most commonly used; therefore, this guide focuses on Azure-specific configuration.

 Note: Although users must log into both RSM InTime and InPay separately, most users access InPay directly through InTime

Step 1 - Register an Application in Azure

The layout shown in the Azure screenshots may differ slightly from your own portal.

  1. Log in to your Azure portal and navigate to Azure Active Directory.

  2. Select App registrations.

991b1893-8ee4-43f0-8e84-8758599baba6.png

  1. Click New registration.

Screenshot 2.png

  1. On the Register an application page, update the following fields:

  • Name: Enter an easy to reference name (e.g. “RSM SSO”)

  • Redirect URI

    • Set Platform to Web.

    • Enter the URI following format https://<yourInTimeDomain>/openid/auth

      • This must match the redirect address shown in InTime > Settings > Security Settings : IDENTITY PROVIDER section.

Your completed application page should look similar to the screenshot provided.

Untitled_v2-20250423-120859.png

  1. Click Register.

Step 2 - Create a Secret in Azure

Now that your InTime Azure application has been created, you must generate a secret. This will allow InTime to authenticate against your Azure application.

To create a secret:

  1. In the application menu, click Certificates & secrets (left-hand navigation).

  2. Click New Client Secret.

  3. Enter a Description and select the appropriate Expiration option.

Untitled4.png

  1. Click Add

  2. Copy the Value of the secret (not the ID). You will need this to configure InTime later.

Untitled5.png

Step 3 - Enable ID Tokens in Azure

To allow Azure to issue ID tokens, update your app configuration:

  1. Click Authentication.

  2. Navigate to the Implicit grant and hybrid flows section.

  3. Tick the box labelled ID tokens.

Untitled6.png

  1. Click Save

Step 4 - Verify API Permissions in Azure

Before proceeding to configure InTime, ensure your Azure application has the correct API permissions assigned.

  1. In your Azure application, navigate to API permissions (left-hand navigation).

  2. Confirm the following permission is listed:

    • Microsoft Graph > openid

  3. If not already present:

    • Click Add a permission.

    • Select Microsoft Graph > Delegated permissions.

    • Search for and select openid, then click Add permissions.

  4. Click Grant admin consent if required by your organisation’s policies.

Verifying these permissions ensures that Azure can issue the necessary tokens for SSO authentication.

Step 5 - Configuring InTime

We recommend that you are logged in to InTime and your Azure portal (or Identify provider) simultaneously for the next step.

  1. Within InTime navigate to:

Settings > Security Settings

  1. If the Settings menu is unavailable, contact your system administrator to ensure your user role has appropriate access.

Untitled7.png

  1. Scroll down to the Identity Provider section.

Populate the following fields:

a. Within your newly created Azure application, click on Endpoints.

b. Azure will provide a list of endpoints relating to your application. Copy the value in the field OpenID Connect metadata document.

Untitled8.png

c. Paste the OpenID Connect metadata document in to the Metadata URL field or the IDENTIFY PROVIDER section of InTime

Untitled9.png

d. Click Load Configuration to auto populate the additional endpoint settings.

e. Populate openid email in to the Requested Scopes field.

f. Populate your Azure application client ID in to the Client ID field.

The application client ID as displayed in Azure
Untitled10.png
Populate within InTime
image-20250423-161650.png

  • Populate the secret created in Step 2 in to the Client Secret field within InTime

image-20250423-161905.png

The IDENTITY PROVIDER section in InTime should now resemble the example screenshot provided.

image-20250423-162051.png

Click Save

Step 6 - Test Single Sign On

To verify SSO is configured correctly:

  1. Attempt to log in to InTime using your Azure credentials.

  2. Ensure the user:

    • Navigates to the correct InTime login URL.

    • Logs in using their email address, not their InTime username.

Troubleshooting

If users are unable to authenticate using Single Sign-On, try the following checks (click to expand):

Cause: Incorrect or expired Client Secret in InTime.

Fix:

  • Recheck the value copied from Azure > Certificates & secrets.

  • Ensure the value entered in InTime is the Secret Value (not the ID).

  • If expired, create a new client secret and update it in InTime.

Cause: The Redirect URI in Azure doesn't match what's configured in InTime.

Fix:

  • Go to Azure > App registrations > Your App > Authentication.

  • Ensure the Redirect URI is set to:

    https://<yourInTimeDomain>/openid/auth

  • Confirm the same URI is shown under InTime > Settings > Security Settings > Identity Provider.

Cause: Azure permissions not correctly configured, or user not assigned to the app.

Fix:

  • Go to Azure > Enterprise Applications > Your App > Users and groups.

  • Make sure the user or group is assigned.

  • Check API permissions include openid (see Step 4).

Cause: Metadata URL is incorrect or not reachable.

Fix:

  • Go to Azure > App > Endpoints.

  • Copy the value from OpenID Connect metadata document.

  • Ensure it’s pasted exactly into InTime > Metadata URL.

Cause: User may be using incorrect credentials or login method.

Fix:

  • Ensure user navigates to the correct InTime login URL.

  • Confirm they’re using their email address, not InTime username.

  • Try logging in with an admin/test account first.

If, after performing all the troubleshooting steps above, users are still unable to log in using Single Sign-On, we recommend the following:

Delete the existing Azure application and reconfigure it from scratch, carefully following each step of this guide.

This ensures any misconfigured values, expired secrets, or overlooked settings are fully reset and correctly applied.

Related content