How to Get Listed in the Okta Integration Network and Entra App Gallery

To list a SaaS app in the Okta Integration Network (OIN) and the Microsoft Entra app gallery, you build one multi-tenant integration (SAML 2.0 or OpenID Connect single sign-on, and optionally SCIM 2.0 provisioning), prepare customer-facing documentation, a support contact and a logo, and then go through two separate submission and review processes. Okta handles submissions in the OIN Wizard inside the Admin Console of a free Okta Integrator Free Plan org. Microsoft handles them in a self-service publishing experience in the Entra admin center, after you have validated each capability yourself.

The engineering is mostly shared, but the two catalogs disagree on a few details that matter, most notably how your SCIM endpoint authenticates. This post walks through both flows as the vendors currently document them, and flags the places where one codebase may need to behave differently per catalog.

Why do these listings matter for a SaaS vendor?

Enterprise administrators tend to start in the catalog of the identity provider they already run. An IT admin who uses Okta or Entra ID opens the app catalog, searches for your product and expects a guided configuration page. If you are not there, the admin has to build a custom SAML or OIDC app by hand from your documentation, which is slower and more error-prone, and it is one more reason for a deal to stall. If you want background on how the two identity providers differ for your customers, Okta vs Entra ID compares them.

Listings also help during security and procurement review, where a reviewer often asks whether the product supports SSO and automated provisioning with the identity provider the company already uses. A catalog entry is a quick, checkable answer, although it does not replace the rest of the questionnaire (we wrote about that gap in SSO doesn’t mean you pass procurement). If you are still deciding what your SSO layer should look like, how to choose an SSO provider for B2B SaaS covers the build-or-buy side.

What do both catalogs expect before you apply?

The checklist overlaps heavily, with a few differences worth seeing side by side.

The Okta items come from Okta’s OIN submission requirements and Publish an OIN integration. The Entra items come from Microsoft Learn’s Prerequisites to validate and publish your app, SSO requirements and user provisioning requirements. Both vendors revise these pages, so read the current versions before you start.

If you have not yet chosen a protocol, SAML vs OIDC: when to use which explains the trade-offs, and the SSO implementation guide for developers walks through the build. Both catalogs accept either one. Microsoft’s SAML requirements accept service-provider-initiated flows, identity-provider-initiated flows, or both, and IdP-initiated vs SP-initiated SSO describes what each means.

How do you submit an app to the Okta Integration Network?

Okta says it is free to submit and list an integration in the OIN. SSO (SAML and OIDC) and SCIM lifecycle management integrations are submitted through the OIN Wizard in the Admin Console of an Okta Integrator Free Plan org, and the same wizard also accepts entitlement management, universal logout, API service and identity verification integrations. The OIN Manager is now used only for Workflows connectors, and Okta states that SSO and SCIM integrations previously submitted through it were migrated to the wizard. The details below follow Okta’s Submit an integration with the OIN Wizard guide and its SCIM variant, which covers the SSO and SCIM cases this post is about.

1. Sign up for an Integrator Free Plan org and sign in as a user with the super admin role, or with both the app admin and org admin roles. Use an account with your company domain email, because Okta does not review submissions from personal email addresses.
2. Build the integration and fill in the wizard: catalog details (name, description, use cases, logo), tenant settings, support contacts, authentication settings for SCIM, and the protocol configuration.
3. Enter a test admin account for the OIN team when the wizard asks for it, generate test app instances, and run the tests it asks for. The testing phase uses the Okta OIN Submission Tester app, which needs Google Chrome, the Okta Browser Plugin with Allow in Incognito enabled, and a password-only app sign-in policy.
4. For SCIM, run Okta’s SCIM API specification tests and CRUD tests in Runscope (a BlazeMeter API testing tool) and paste the two result URLs into the submission.
5. Certify that you completed the required tests and submit.

After submission Okta emails you the expected date for the initial review. The review has an initial phase and a QA testing phase, Okta emails you at each phase with the status and expected completion date, and if the team finds problems it sends the list back for you to fix and resubmit. You can follow the status on the Your OIN Integrations dashboard.

Which Okta details catch teams out?

Okta’s requirements point to these common failure points:

• A submission from a personal email account, which is not reviewed.
• A logo in the wrong size, or a wordmark (a graphic that includes the product name) instead of an icon. Okta accepts a few specific dimensions, such as 200 by 200 pixels for a square logo, under one MB.
• Missing Runscope spec test or CRUD test result URLs for a SCIM integration.
• Test account credentials that are not active during review. Okta deletes them 30 days after publication, so a later resubmission needs a fresh account.
• SCIM attribute mappings that claim attributes your app does not support. Okta’s wizard starts with default mappings and says the submission should reflect only what your app supports.
• A SCIM server that uses basic authentication, or an app that is not multi-tenant.

How do you publish an app to the Microsoft Entra app gallery?

Microsoft separates validation from publishing. You validate each capability yourself first, and then you create a submission that references those results. The flow below follows Microsoft Learn’s Publish your app to Microsoft Entra App Gallery.

1. Meet the prerequisites. Agree to the gallery terms and conditions, have a production-ready app, set up engineering and support contacts, publish customer documentation for each capability, create a test tenant (the Microsoft 365 Developer Program is one way to get one), and associate your organization with the Microsoft AI Cloud Partner Program with a Partner One ID.
2. Validate each capability separately. SAML, OIDC and user provisioning each have their own validation article. Test SAML and provisioning against a non-gallery app first, as the requirements articles describe.
3. Create the submission. In the Entra admin center, go to Enterprise applications, select Browse Microsoft Entra App Gallery, and choose Publish your application to gallery. Enter the app name and your Partner One ID and save, which creates a Submission ID that you keep for the rest of the process.
4. Select capabilities and attach results. Choose Single Sign-On, or Single Sign-On plus User Provisioning, and associate the validation results.
5. Complete the details and upload assets. Review the prefilled publisher and app information, upload documentation, and add two PNG logos with transparent backgrounds: 215 by 215 pixels and 150 by 122 pixels.
6. Submit. The submission moves from Draft to Submitted, and then through Under Review, Approved, In Preview and Published.

What does the OIDC path add?

For OIDC, the SSO requirements say to use the OAuth 2.0 authorization code flow (not the resource owner password flow), the Microsoft identity platform v2.0 endpoint, and a confidential client, because the gallery does not onboard public clients. You must complete publisher verification with your Microsoft AI Cloud Partner Program ID, and an app that uses the client credentials flow must authenticate with a certificate rather than a client secret. A multitenant app is expected for cloud SaaS, though a single-tenant app is acceptable when you deploy a separate instance for each customer.

What are the SCIM gates for Entra?

The user provisioning requirements ask for a SCIM 2.0 user endpoint (groups recommended), schema discovery, soft or hard deletes, at least 25 requests per second per tenant, and a successful empty response when a queried user does not exist. The empty-response rule matters because the provisioning service looks a user up before creating one, and Microsoft’s validation guide lists a 404 on an empty query as a failure on your side. Our SCIM API build-and-test guide covers building these endpoints, the SCIM tester can exercise yours, and what SCIM is and why it matters gives the background.

Two further gates are specific to Microsoft. The requirements list deploying your SCIM integration to at least 100 mutual customers by using the non-gallery approach. And the validation article, which Microsoft marks as a preview, has you run an Azure Logic Apps template that executes 25 tests (7 user, 7 group and 11 SCIM compliance). You need an Azure subscription with at least the Logic App Contributor role, and Microsoft puts the cost typically under 10 USD per month. The bearer token for the run has to stay valid for at least 24 hours, because a run takes 60 to 90 minutes.

How long do the reviews take?

Neither vendor guarantees a duration, but both give some guidance. Okta emails an expected initial-review completion date for each submission and again at each phase. Microsoft’s publishing article gives a timeline example: Under Review within about 5 business days, Preview within about 10 business days after approval, and public availability within about 7 business days once all requirements are met. Microsoft adds that actual times vary with how complete the submission is and whether more information is needed, so treat those numbers as an illustration.

Which SCIM authentication does each catalog accept?

This is the one place where a single SCIM base URL may need to behave differently depending on who is calling it. In Okta’s wizard, authentication to your SCIM server can be a header token, a bearer token, or the OAuth 2 authorization code grant, and basic authentication is not supported. Microsoft does not onboard SCIM apps that use basic authentication, long-lived bearer tokens or the authorization code grant, and expects OAuth 2.0 client credentials or workload identity federation instead. With client credentials, Microsoft requires client secrets that expire after one to three years, rotation with multiple active secrets, and access tokens that expire between 60 minutes and six hours.

The practical result is that an endpoint built for the Okta listing with a static bearer token will not pass Microsoft’s requirements, and an endpoint that only accepts client credentials will need a token-based mode (or the OAuth 2 authorization code grant) for Okta. Plan the authentication layer so it can accept both schemes on the same SCIM routes, and keep the credentials per tenant (Okta’s OAuth 2 mode is the exception: its client ID and secret are shared across every customer tenant, so per-tenant isolation has to come from the tokens it obtains).

Where do the two catalogs differ on protocol limits?

Okta’s OIN limitations section documents several constraints that shape your integration:

• OIDC: integrations must use the org authorization server (not a custom one, including the default), the Web Application app type and the authorization code flow. Refresh tokens and the offline_access scope are not supported, and custom scopes such as groups are not available.
• SAML: SHA256 signing is required, there is a maximum of three app instance variables for per-tenant settings, and SP-initiated Single Logout is not supported.
• SWA: Okta no longer publishes new Secure Web Authentication integrations, so password-based sign-in through the browser plugin is not a path to a new listing.

Microsoft, by contrast, lists SAML Single Logout as recommended, and expects least-privilege Graph permissions and delegated permissions where your OIDC app calls Microsoft Graph. If you plan to support both, do not make a group claim delivered through a custom OIDC scope your only way to receive groups. Provision groups through SCIM, or read them from a SAML attribute, and treat single logout as optional in your design.

How do you serve both listings from one codebase?

Keep the identity-provider-facing surface standards-based and identical for every customer, and push everything that varies into per-tenant configuration. That means one SAML assertion consumer service or OIDC redirect handler that resolves the tenant from the request, one SCIM base URL with per-tenant credentials, and one settings screen where an admin pastes in or uploads their IdP’s metadata. A few habits make this easier:

• Accept IdP metadata by URL as well as by file upload, so certificate rotation does not need a support ticket. Microsoft recommends consuming its federation metadata URL for this reason.
• Make attribute names configurable per tenant, since Okta, Entra ID, Google Workspace and others send different defaults.
• Implement SCIM against the specification and test it with more than one client, because Okta and Entra can send different filter queries and PATCH shapes.
• Reuse the documentation structure for each provider, swapping in IdP-specific screenshots. Both catalogs require public documentation, and writing it usually takes the longest.

If you would rather not build the SAML, OIDC and SCIM plumbing yourself, an identity management as a service (IDaaS) layer can sit between your app and your customers’ identity providers. Skycloak, our managed service built on Keycloak, fills that role with its single sign-on and SCIM features. You can inspect what your service provider sends with the SAML decoder while you debug.

What should you do next?

Start by deciding on the tenancy model and the SSO protocol, then build SCIM with an authentication layer that can accept both Okta’s and Microsoft’s schemes. Run Okta’s Runscope tests and Microsoft’s Logic Apps validation against the same endpoint, and write one public setup guide per provider. Create the Integrator Free Plan org and the Partner One ID early, since both are prerequisites for the submission screens. After that, submit to each catalog separately, expect questions, and keep your test account active until you hear back.

Frequently asked questions

Do I need SCIM to get listed?

No. SCIM is a separate integration type in both catalogs, and you can list SSO alone. If you add SCIM, Microsoft’s requirements add the 100 mutual customer deployment, the Logic Apps validation and its authentication rules, so check them before committing to a date.

Should I choose SAML or OIDC for the gallery?

Both catalogs accept either. Choose the protocol your target customers’ administrators ask for, and keep Okta’s OIDC limits (org authorization server, no refresh tokens, no custom scopes) and Microsoft’s OIDC requirements (confidential client, publisher verification) in mind. The comparison of SAML and OIDC has more on the trade-offs.

How long does review take?

Okta emails an expected initial-review date for each submission, and Microsoft’s example timeline is about 5 business days under review, about 10 to reach Preview and about 7 more to become publicly available. Both caveat that actual time depends on your submission.

Do I need a paid Okta or Microsoft account to submit?

Okta says submitting and listing is free, and the wizard runs in an Integrator Free Plan org that you sign up for, using a company-domain email. Microsoft requires a Partner One ID in the Microsoft AI Cloud Partner Program, and SCIM validation needs an Azure subscription with the Logic App Contributor role, which Microsoft says typically costs under 10 USD per month.

Why does Entra reject my SCIM endpoint when Okta accepted it?

The most likely cause is authentication. Microsoft does not onboard SCIM apps that rely on basic authentication, long-lived bearer tokens or the authorization code grant, and the validation article notes that a static bearer token is acceptable for running validation only. Production publishing needs OAuth 2.0 client credentials or workload identity federation. Lookups for a user that does not exist also have to return a successful empty result, and the validation article treats a 404 there as something to fix in your endpoint.

Does being listed mean customers can set up SSO without my help?

Mostly, as long as your documentation is good. A listing gives the admin a guided starting point, but they still have to enter tenant-specific values and assign users. The quality of your setup guide and the responsiveness of your support contact decide whether a customer finishes without opening a ticket.