There are two halves to an Entra integration, and most enterprise customers run both on the same enterprise application: SAML SSO controls how your team signs in, and SCIM provisioning controls who has a store account in the first place — accounts are created when employees join and deactivated when they leave, with no manual user admin. Set up SSO first, then add SCIM.
The values you'll paste into Microsoft Entra. All four URLs are scoped to your store and never change.
user.mailOnce the integration is live, signing in from Microsoft My Apps works right away. Sign-in started from the swag store itself is switched on per store — it uses the same Entra configuration, we just need your Login URL (see the final step below).
Users open myapps.microsoft.com and click the tile for
your swag store. Entra posts a signed assertion to store.jaapi.store and they land logged in.
IdP-initiated. No extra configuration needed.
Users go to store.jaapi.store/auth/signin and click Sign in with SSO. We redirect them to Entra to authenticate,
then back to the store.
SP-initiated. Requires you to share your Entra Login URL with Jaapi (see the final step below).
You'll need the Cloud Application Administrator or Application Administrator role. The whole setup takes about ten minutes.
entra.microsoft.com.On the SAML configuration page, edit each numbered section with the values below. Values must match exactly for authentication to work.
Click Unique User Identifier (Name ID) and configure:
user.mailThe SAML NameID (email) is the only required attribute. You
can optionally send these from Section 2's Additional claims to populate the user's profile on first
login.
nameDisplay name. Source attribute: user.displayname. Use the
short claim name name (clear the default namespace).
avatarProfile picture URL. Source attribute: a custom extension attribute that holds a publicly fetchable image URL. Skip this claim if you don't have one.
After finishing the SAML configuration, send Jaapi the information below so we can pin your IdP certificate and enable the SSO tile on your storefront.
myapps.microsoft.com as the test user and
click your application's tile. The first attempt will fail — this is
expected.store.jaapi.storeWhy the first login fails
We don't trust any IdP certificate by default. Your first sign-in attempt is rejected on purpose; the certificate from that attempt is captured for review. Once we verify it matches the file you sent over, we pin it and your team can sign in normally. This prevents anyone from impersonating your IdP during onboarding.
Later certificate renewals are self-service: when Entra rotates your signing certificate, a store admin can paste the new one under SAML SSO in the store settings — no need to email us again.
The values you'll paste into Entra's provisioning settings.
SSO decides how people sign in; SCIM decides who has an account in the first place. With provisioning enabled on the same enterprise application, Entra creates a store account when an employee is assigned the app, keeps their name and email in sync, and deactivates them when they're offboarded — so your store mirrors who's active in Entra, with no manual invites.
For the full list of supported endpoints, attributes and behaviours, see the SCIM 2.0 reference.
Entra ID P1 required
Automatic provisioning to a non-gallery (custom) application requires Microsoft Entra ID P1 or higher. If the Provisioning blade only offers manual provisioning, check your licence tier.
Under Mappings → Provision Microsoft Entra ID Users, the
defaults are close, with one thing to verify: userName must
carry the user's email address, because it has to match
the email your SAML sign-in sends (user.mail). Entra's
default maps userPrincipalName → userName, which
is fine only if UPNs equal email addresses in your tenant — otherwise
change the source attribute to mail.
Beyond that, givenName, surname, displayName, emails and the active flag are all
we consume — extra default mappings are ignored harmlessly. Leave Provision Microsoft Entra ID Groups disabled: Jaapi is
the downstream system and uses a flat role model, so it doesn't consume
groups.
Good to know
active: false rather than deleting — departed employees
lose store access immediately, while their order history is retained.