Single Sign On

Azure Entra ID Configuration 

Single Sign-On (SSO) Setup Guide for Customers 

IMPORTANT: App Registration Type 

This guide covers Entra App Registration with Client Secret authentication. Do NOT use Entra Enterprise App or SAML configuration. If you need to set up SAML-based SSO, please contact RTA Support for alternative guidance. 

Overview 

This document provides step-by-step instructions for configuring Single Sign-On (SSO) in Microsoft Entra ID (formerly Azure AD). Your IT team will need to create an App Registration with specific permissions to enable RTA Fleet to authenticate your users. 

What You Need 

  • Access to Microsoft Entra ID (Azure AD) admin portal 

  • Permissions to create App Registrations 

  • Ability to manage API permissions 

  • Permission to create and manage application credentials (Client Secrets) 

Step-by-Step Setup Instructions 

Step 1: Navigate to App Registrations 

  1. Go to the Microsoft Entra admin center at  https://entra.microsoft.com 

  2. In the left navigation menu, select Identity > Applications > App registrations 

Step 2: Create a New Registration 

  1. Click the  + New registration button 

  2. Enter a name for the application (e.g., RTA Fleet SSO) 

  3. Under Supported account types, select Accounts in this organization only (Single tenant) 

  4. Click Register 

Step 3: Configure Redirect URI 

Important: The Redirect URI tells Entra where to send users after they authenticate. This must be set correctly for SSO to work. 

  1. From your app registration, go to Manage > Authentication 

  2. Under Platform configurations, click + Add a platform 

  3. Select Web 

  4. Under Redirect URIs, enter: https://rtafleet.auth0.com/login/callback 

  5. Under Front-channel logout URL (optional), you may enter: https://rtafleet.auth0.com/logout 

  6. Check the box for ID tokens (used for implicit and hybrid flows) 

  7. Click Configure 

Step 4: Configure API Permissions 

Important: Your app needs delegated permissions to read user information from Microsoft Graph. 

  1. From your app registration, go to Manage > API permissions 

  2. Click + Add a permission 

  3. Select Microsoft Graph 

  4. Choose Delegated permissions 

  5. Search for and add the following permissions: 

  • User.Read  

  • (Allows the app to read basic user profile information) 

  1. After adding all permissions, click Grant admin consent for [your organization] 

Step 5: Create Client Secret 

Warning: Store your Client Secret securely. You will only see it once. 

  1. From your app registration, go to Manage > Certificates & secrets 

  2. Under the Client secrets section, click + New client secret 

  3. Enter a description (e.g., RTA Fleet SSO Secret) 

  4. Select an expiration period (we recommend 24 months) 

  5. Click Add The secret will appear. Copy and save the VALUE (not the Secret ID). You will not be able to see this value again. 

Step 6: Gather Required Information 

Once you complete the above steps, collect the following information to send to RTA Support: 

Item 

Where to Find It 

Tenant ID 

App registration Overview page 

Client ID 

App registration Overview page (labeled as Application ID) 

Client Secret Value 

Certificates & secrets page (the VALUE, not the Secret ID) 

 

Next Steps 

  1. Once you have collected all the information above, contact RTA Support 

  2. Provide your IT contact person with the gathered information 

  3. RTA will configure the connection on our end 

  4. RTA will send you a login link to authorize and test the connection 

Keep secret values out of chat and email. Never paste a Client Secret value, private key, or certificate file into a chat message or email. When sensitive values have to change hands, Support will tell you the secure way to deliver them.

Troubleshooting 

I cannot create an App Registration 

  • You need to have administrator privileges in Entra ID. Contact your IT department to ensure you have the Application Administrator or Cloud Application Administrator role. 

I cannot add permissions 

  • Ensure you have properly selected Delegated permissions (not Application permissions). You may also need an administrator to grant consent for the permissions. 

I lost my Client Secret 

  • Client Secrets are only displayed once at creation. If you lose the value, you must create a new Client Secret in the Certificates & secrets section. The old one can be deleted. 

 Questions? 

Contact RTA Support for assistance with SSO setup or configuration troubleshooting. 

Renewing a Client Secret Before It Expires

Client Secrets expire on the schedule chosen when they were created (this guide recommends 24 months). When the secret expires, SSO sign-ins stop working until a new secret is in place on both sides — so renewals should be coordinated with RTA Support before the expiration date, not after sign-in breaks.

  • Contact Support early. Tell Support which integration is involved (for example, your Fleet360 SSO app registration), the expiration date, and which environment or environments are affected (production, test, or training). That is all Support needs to start the renewal.

  • Do not send secret values. Support does not need, and you should never send, a Client Secret value, private key, or certificate file through chat or email. When the new secret is ready, Support will tell you the secure way to deliver it.

  • Renew by adding, not editing. A Client Secret cannot be extended — create a new secret in Manage > Certificates & secrets on the same app registration (as in Step 5). Once the new secret is in place and sign-in is confirmed working, the old secret can be deleted, so there is no sign-in interruption.

  • Already expired or unsure which certificate? If the secret has already expired and users cannot sign in, or you are not sure which app registration or certificate is involved, contact RTA Support right away and say the expiration is affecting sign-in now.

Multi-Tenant SSO

If your organization has more than one Fleet360 environment — for example, a production environment alongside a test or training environment — SSO can be configured to work across all of them. Once provisioned, a user logs in once through SSO and can switch between their authorized environments without re-authenticating.