ShareDo can rely on O365 (technically Azure Active Directory) to authenticate users. In order to allow this, ShareDo must be configured as an application within O365, and then O365 added to ShareDo as an identity provider.
To use O365 for authentication in ShareDo, you need to follow these steps.
- Step 1: Create a new App Registration.
- Step 2: Configure Authentication for the Azure AD App Registration.
- Step 3: Capture the App Registration settings you will need.
- Step 4: Configure O365 Authentication in ShareDo.
- Step 5: Test Authentication with SSO.
Step1: Create a new App Registration
- Open the Azure portal at https://portal.azure.com.
- Open the Azure Active Directory resource.
- Create a New registration.
- Complete the information required for the new app registration.

- Give the application a name [Client AAD App RegistrationName].
- Select Accounts in this organizational directory only.
- Select the platform as Web.
- Complete redirect URI.
- The Redirect URI for authentication should be set to the name of your identity server tenant. Your project team will let you know what this is – for example, https://[customer]-identity.ShareDo.co.uk
- Click Register to create the app registration.
The new App Registration is created, and you are presented with its portal. To make this work for single sign-on (SSO), you must complete the additional steps below.
- Navigate to the Authentication page.
- Confirm your Redirect URI has been created in a Web Platform section.
- Enable implicit flow.
- Ensure you Save these settings.
- Navigate to the API Permissions page.
- Ensure there is an API Permission for User.Read and that this does not require Admin Consent.
If your environment does require consent, select the option to Grant admin consent.
Step 3: Capture the App Registration settings you will need
- Navigate to the Overview page.
- Capture the Application (client) ID.
- Capture the Directory (tenant) ID.
- .Capture the OAuth 2.0 endpoint:
- Open Endpoints and copy this value.
ShareDo ships with an out-of-the-box AAD provider. You can configure this or create a new one.
- Navigate to the ShareDo Administration Portal.
-
Integrations > Manage Identity Server.
- To configure the existing provider, click it to open the blade.
- To create a new one, click Add Provider > Add OpenID provider.
- Complete the details required in the blade.

-
OpenId Authority: Enter the “OAuth 2.0 authorization endpoint (v2)”, but remove everything after the GUID (i.e. remove
oauth2/v2.0/authorize). This is commonly https://login.microsoftonline.com/[tenantId]/
-
OpenId Client Id: Enter the Application (client) ID captured in Step 3.
-
OpenId Post logout URL: Set this to the URL of your ShareDo instance - i.e. https://[customer].ShareDo.co.uk
-
OpenId Custom Meta URL: The metadata URL enables an application to automatically find the provider's configuration, removing the need to hardcode endpoints. The metadata document is usually located at a recognised path, such as /.well-known/openid-configuration, relative to the issuer's base URL. This is a way to override where the well-known openid-configuration resides on the upstream identity provider. Normally leave this blank.
-
OpenId Scopes: If left empty, this field defaults to openid profile, otherwise, it uses the entered value. OIDC scopes define user info an application requests during authentication, specifying access privileges for tokens and affecting available user attributes (claims). The mandatory
openid
scope authenticates users and provides a unique identifier (sub
claim). Other common scopes include profile
, email
, and address
, which grant access to specific user details.
-
OpenId Response Times: OIDC response times are related to the lifespan of access tokens, refresh tokens, and ID tokens. Access tokens typically last for a few minutes to a few hours, while refresh tokens can last much longer, even years. ID tokens have a default lifetime of 60 minutes. Usually, an open ID provider will use code id_token.
-
Client Secret: Enter an optional client secret. You would get this from the configured client app within the upstream OpenID provider.
- Complete the Advanced Settings section.

- UPN is the most common claim used to match the authenticated AAD user to the ShareDo user record. However, it is not always provided in all circumstances (e.g., guest account access).
The identity claim setting here will match multiple comma-separated claims in order of precedence, so you can also have “upn, email” and it will match on “upn” first and if not available, then “email”.
- If you are using seamless authentication with O365, so that accessing O365 instantly signs you in with no interaction, you will want to specify the post logout URL as your ShareDo tenant /security/signedOut – otherwise, when a user signs out, they will be redirected to ShareDo, which in turn will redirect to O365, instantly sign them in, and return back to ShareDo – rendering sign out ineffective.
- Click Save, ShareDo will ask if it’s ok to restart identity server, click Yes and Office 365 authentication is configured with ShareDo. You will now need to configure some users.
Step 5: Test Authentication with SSO
- Navigate to the ShareDo Administration Portal.
-
Users > All.
- Create a new user.

- Note that users can be automatically provisioned from AAD. This is discussed in the following help topic Adding O365 Users to ShareDo.
- Navigate to the User Account blade.
- Configure the identity settings.

-
Active: Ensure the user is set to active.
-
Identity Provider: Select the Identity Provider we created in Step 4.
-
Identity Claim: This is the value that will be mapped to the claim configured in Step 4.6 - Advanced Settings. This is usually the user's UPN or email address.
-
Test the integration: Log in to your ShareDo instance by selecting the login button configured for your provider.
Once this is successful, you can plan to disable Forms Authentication for ShareDo. If AAD is the only mechanism available for login, users will not see this login screen; they will be seamlessly logged in.