Merge pull request #43124 from ArvindHarinder1/patch-66

Update use-scim-to-provision-users-and-groups.md

Author: Jak-MS

articles/active-directory/manage-apps/use-scim-to-provision-users-and-groups.md

@@ -1308,6 +1308,24 @@ Once the initial cycle has started, you can select **Provisioning logs** in the
 
 If you're building an application that will be used by more than one tenant, you can make it available in the Azure AD application gallery. This will make it easy for organizations to discover the application and configure provisioning. Publishing your app in the Azure AD gallery and making provisioning available to others is easy. Check out the steps [here](https://docs.microsoft.com/azure/active-directory/develop/howto-app-gallery-listing). Microsoft will work with you to integrate your application into our gallery, test your endpoint, and release onboarding [documentation](https://docs.microsoft.com/azure/active-directory/saas-apps/tutorial-list) for customers to use. 
 
+
+### Authorization for provisioning connectors in the application gallery
+The SCIM spec does not define a SCIM-specific scheme for authentication and authorization. It relies on the use of existing industry standards. The Azure AD provisioning client supports two authorization methods for applications in the gallery. 
+
+**OAuth authorization code grant flow:** The provisioning service supports the [authorization code grant](https://tools.ietf.org/html/rfc6749#page-24). After submitting your request for publishing your app in the gallery, our team will work with you to collect the following information:
+*  Authorization URL: A URL by the client to obtain authorization from the resource owner via user-agent redirection. The user is redirected to this URL to authorize access. 
+*  Token exchange URL: A URL by the client to exchange an authorization grant for an access token, typically with client authentication.
+*  Client ID: The authorization server issues the registered client a client identifier, which is a unique string representing the registration information provided by the client.  The client identifier is not a secret; it is exposed to the resource owner and **must not** be used alone for client authentication.  
+*  Client secret: The client secret is a secret generated by the authorization server. It should be a unique value known only to the authorization server. 
+
+Best practices (recommended but not required):
+* Support multiple redirect URLs. Administrators can configure provisioning from both "portal.azure.com" and "aad.portal.azure.com". Supporting multiple redirect URLs will ensure that users can authorize access from either portal.
+* Support multiple secrets to ensure smooth secret renewal, without downtime. 
+
+**Long lived OAuth bearer tokens:** If your application does not support the OAuth authorization code grant flow, you can also generate a long lived OAuth bearer token than that an administrator can use to setup the provisioning integration. The token should be perpetual, or else the provisioning job will be [quarantined](https://docs.microsoft.com/azure/active-directory/manage-apps/application-provisioning-quarantine-status) when the token expires. This token must be below 1KB in size.  
+
+For additional authentication and authorization methods, let us know on [UserVoice](https://aka.ms/appprovisioningfeaturerequest).
+
 ### Allow IP addresses used by the Azure AD provisioning service to make SCIM requests
 
 Certain apps allow inbound traffic to their app. In order for the Azure AD provisioning service to function as expected, the IP addresses used must be allowed. For a list of IP addresses for each service tag/region, see the JSON file - [Azure IP Ranges and Service Tags – Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519). You can download and program these IPs into your firewall as needed. The reserved IP ranges for Azure AD provisioning can be found under "AzureActiveDirectoryDomainServices."