Skip to Content
Platform AdministrationIDP Authentication

Identity Provider Authentication

Configure Single Sign-On (SSO) with Microsoft Entra ID using either OIDC or SAML protocols, and set up SCIM provisioning for automated user lifecycle management.

For a quick overview of SSO setup across multiple identity providers (Azure AD, Okta, Google Workspace), see the SSO & SCIM getting started guide.

Where to configure what in Azure

Microsoft splits configuration by design. Use the right place for each feature:

  • App Registration → OIDC/SSO only (client ID, client secret, redirect URIs, API permissions)
  • Enterprise Application (non-gallery) → SCIM provisioning (Provisioning → Tenant URL + Secret Token), SAML SSO (if used), and user/group assignment

For SCIM user provisioning, configure the Enterprise Application, not the App Registration.

Choosing a protocol

OpenID Connect (OIDC) — Modern, token-based authentication using OAuth 2.0.

Choose OIDC if you prefer modern APIs and token-based authentication, need mobile app support, want easier integration with REST APIs, or require API permissions for additional data access.


OIDC configuration with Microsoft Entra ID

Create App Registration in Azure Portal

Navigate to Azure Portal → Azure Active Directory → App registrations → New registration.

FieldValue
NameSecureHive - [Your Organization]
Supported account typesAccounts in this organizational directory only
Redirect URIWeb — https://yourdomain.com/auth/sso/callback

Configure authentication

In your app registration, go to Authentication → Add a platform.

  • Platform: Web
  • Redirect URIs:
    • https://yourdomain.com/auth/sso/callback
    • https://yourdomain.com/auth/sso/logout
  • Front-channel logout URL: https://yourdomain.com/auth/sso/logout

Configure API permissions

Go to API permissions → Add a permission → Microsoft Graph. Add the following delegated permissions:

PermissionPurpose
openidSign users in
profileView users’ basic profile
emailView users’ email address
User.ReadSign in and read user profile

Get application credentials

Navigate to Overview and copy the following values:

  • Application (client) ID — copy this value
  • Directory (tenant) ID — copy this value
  • Client Secret — go to Certificates & secrets → New client secret

Configure in SecureHive

Navigate to Settings → Identity Provider Configuration and enter:

FieldValue
Client IDApplication (client) ID from Azure
Client SecretClient secret from Azure
Redirect URIhttps://yourdomain.com/auth/sso/callback
Issuerhttps://login.microsoftonline.com/{tenant-id}/v2.0

Your OIDC configuration is complete. Users can now sign in using their Microsoft Entra ID credentials.


SAML 2.0 configuration with Microsoft Entra ID

Create Enterprise Application in Azure Portal

Navigate to Azure Portal → Azure Active Directory → Enterprise applications → New application.

FieldValue
NameSecureHive - [Your Organization]
Application typeNon-gallery application

Configure Single Sign-On

In your enterprise application, go to Single sign-on → SAML and set the Basic SAML Configuration:

FieldValue
Identifier (Entity ID)https://sts.windows.net/{tenant-id}/
Reply URL (ACS URL)https://yourdomain.com/auth/saml/acs
Sign on URL (optional)https://yourdomain.com/auth/sso/login

Review User Attributes & Claims

Azure AD automatically configures default SAML claims. No API permissions are required for SAML.

Default claims:

ClaimSource attribute
Unique User Identifier (Name ID)user.userprincipalname
Email Addressuser.mail
Given Nameuser.givenname
Nameuser.userprincipalname
Surnameuser.surname

Optional claims for enhanced functionality:

ClaimSource attribute
Display Nameuser.displayname
Object IDuser.objectid
Groupsuser.groups

SecureHive automatically maps these to user profile fields during authentication.

Download Federation Metadata

Go to Single sign-on → SAML → Download Federation Metadata XML. Save the FederationMetadata.xml file — you’ll need this for SecureHive configuration.

Configure in SecureHive

Navigate to Settings → Identity Provider Configuration.

Method 1 — Upload Metadata: Upload the FederationMetadata.xml file directly.

Method 2 — Manual Configuration:

FieldValue
IDP TypeSAML 2.0
SSO URLhttps://login.microsoftonline.com/{tenant-id}/saml2
Entity IDhttps://sts.windows.net/{tenant-id}/
ACS URLhttps://yourdomain.com/auth/saml/acs
CertificateCopy from FederationMetadata.xml

Your SAML configuration is complete. Users can now sign in using their Microsoft Entra ID credentials via SAML.


SCIM provisioning (Enterprise Application)

SCIM provisioning uses the Enterprise Application (non-gallery app) to automatically sync users from Microsoft Entra ID to SecureHive.

Prerequisites

Before configuring SCIM provisioning:

  • Enterprise Application — a non-gallery Enterprise Application in your tenant (same place you configure SAML if you use it)
  • SCIM token — a per-tenant secret token (32–64 characters) that you will set in both Entra and SecureHive
  • SCIM base URL — your SCIM endpoint (e.g. https://scim.securehive.ai/scim/v2)

Create or use an Enterprise Application

Navigate to Microsoft Entra admin center → Enterprise applications → New application → Create your own application (non-gallery).

FieldValue
NameSecureHive – [Your Organization]
Application typeNon-gallery application

This is the same type of app used for SAML. OIDC/SSO continues to use the separate App Registration.

Enable provisioning and set SCIM endpoint

In the Enterprise Application: Provisioning → Get started → Provisioning mode: Automatic.

FieldValue
Tenant URLhttps://scim.securehive.ai/scim/v2
Secret TokenA bearer token you generate (32–64 character random string)

Store the same Secret Token value in SecureHive SCIM configuration for this tenant.

Configure in SecureHive

In SecureHive, navigate to Settings → Identity (or SCIM settings) for your tenant. Enter the same Secret Token you set in Azure and ensure the SCIM base URL matches.

Configure attribute mappings

In the Enterprise Application: Provisioning → Mappings → Provision Azure Active Directory Users.

externalId (required) — Edit the externalId mapping so the source attribute is objectId, not the default (e.g. mailNickname). SecureHive expects a stable GUID for each user; if Azure sends an alias like “jhua”, provisioning will fail with a validation error.

department (optional) — Add or edit a mapping from Azure department to the SCIM target department (or urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department if your app uses the enterprise extension).

manager (optional) — Add or edit a mapping from Azure manager to the SCIM enterprise extension manager (urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager). Value is typically the manager’s object ID.

Summary

  • App Registration → OIDC/SSO (client ID, secret, redirect URIs)
  • Enterprise Application → SCIM provisioning (Tenant URL + Secret Token), and SAML if you use it
  • One App Registration can serve OIDC for all customers; each customer tenant has its own Enterprise Application instance for SCIM (and optionally SAML)

Troubleshooting

Redirect URI mismatch

Error: “The redirect URI in the request does not match the redirect URIs configured for the application”

Solution: Ensure the redirect URI in Azure matches exactly: https://yourdomain.com/auth/sso/callback

Application not found

Error: “Application with identifier was not found”

Solution: Verify the Entity ID/Identifier in Azure matches the Issuer configured in SecureHive.

SAML response invalid

Error: “SAML message was not properly DEFLATE-encoded”

Solution: Ensure your SAML configuration includes proper certificate and signature settings.

User not provisioned

Error: User signs in successfully but doesn’t appear in SecureHive.

Solution: Check that JIT (Just-In-Time) provisioning is enabled in your IDP configuration.

SCIM provisioning not available

Provisioning is only visible for Enterprise applications (non-gallery). It does not appear under App registrations.

SCIM validation error when creating users

Ensure attribute mapping: externalIdobjectId in the Enterprise Application Provisioning → Mappings.


Best practices

Security:

  • Use HTTPS for all redirect URIs
  • Rotate client secrets regularly
  • Enable certificate-based authentication for SAML
  • Use least-privilege permissions

Operations:

  • Test configuration in staging first
  • Document all configuration changes
  • Monitor authentication logs
  • Have a fallback authentication method
Last updated on