Describe the solution you'd like
Support for login with Single Sign-On provider Okta. For security and convenience, we would like to manage accounts with Okta (SAML).
Describe alternatives you've considered
Alternatively, we could manage employee access via Google (G Suite) accounts. We would like to disable alternative login methods (Facebook, GitHub, username+password).
Additional context
See https://appcenter.ms/sign-in - I haven't found a way to disable login methods.

I was told to create a feature request in regards to having an App Center Okta App. Just adding to this request that we are looking forward to the release of this plugin.
Best regards,
Can we have Okat and Local User which can integrate with the APPCENTER for the login, Please share the reference page
Commenting on a closed issue only because of the importance around enterprise-level account management. SAML and custom OAuth server support from services like OneLogin, Okta and ADFS would be greatly appreciated in order to better support account provisioning and deprovisioning, as well as role and team assignments. Currently, only Azure AD is supported for group membership automation which requires homegrown tooling to automate any sort of assignment. The current level of support through the interface may be acceptable for SMB's but for enterprises on a quick release schedule (10-100x a day) are not thought of, which most likely make up most of the revenue received from the product.
Additionally, there is a lack of robustness around the current API such as the inability to mute/disable invite notifications anytime an App is added to a distribution group or a new user is added to a distribution group, which is not applicable in most enterprise environments.
From a security controls perspective, it would be nice to have the ability to disable local user passwords, or, if the user is added to an enterprise-org, the org has the ability to disable the user account, since user accounts have no affinity at the provisioning level to an organization. This leaves a high level of concern around tedious manual interaction when decommissioning a user, ensuring they are removed from Teams, and Distribution groups, which are discontiguous with organizational membership. Ie, there is not a good story for the difference between organization membership, team membership, and distribution group membership, all of which can have different users and different responsibilities within the platform, which are three separate account management pages that need to be considered.
Thanks!
Also want to make sure that #286 is linked to this ticket as well.
This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.
This issue will now be closed because it hasn't had any activity for 15 days after stale. Please feel free to open a new issue if you still have a question/issue or suggestion.
Most helpful comment
Commenting on a closed issue only because of the importance around enterprise-level account management. SAML and custom OAuth server support from services like OneLogin, Okta and ADFS would be greatly appreciated in order to better support account provisioning and deprovisioning, as well as role and team assignments. Currently, only Azure AD is supported for group membership automation which requires homegrown tooling to automate any sort of assignment. The current level of support through the interface may be acceptable for SMB's but for enterprises on a quick release schedule (10-100x a day) are not thought of, which most likely make up most of the revenue received from the product.
Additionally, there is a lack of robustness around the current API such as the inability to mute/disable invite notifications anytime an App is added to a distribution group or a new user is added to a distribution group, which is not applicable in most enterprise environments.
From a security controls perspective, it would be nice to have the ability to disable local user passwords, or, if the user is added to an enterprise-org, the org has the ability to disable the user account, since user accounts have no affinity at the provisioning level to an organization. This leaves a high level of concern around tedious manual interaction when decommissioning a user, ensuring they are removed from Teams, and Distribution groups, which are discontiguous with organizational membership. Ie, there is not a good story for the difference between organization membership, team membership, and distribution group membership, all of which can have different users and different responsibilities within the platform, which are three separate account management pages that need to be considered.
Thanks!
Also want to make sure that #286 is linked to this ticket as well.