Back to Overview

Microsoft Azure App Setup

Register one Microsoft Azure app for Outlook Calendar sync and Microsoft Teams meeting creation.

Luka Breitig, Software Engineer & AI Developer
Luka Breitig

Mis à jour le 18 septembre 2026

Before you begin

  • A Microsoft account or an Azure account (a free account at azure.microsoft.com is sufficient)
  • A domain with HTTPS configured
  • Tymeslot installed and running at your domain

By the end of this guide, one Azure app registration serves both Outlook Calendar sync and Teams meeting creation.

One App Registration, Two Features

One Azure app registration covers both Microsoft integrations in Tymeslot, so you only go through this setup once. Microsoft sign-in to Tymeslot itself is not part of it; for that, see the OIDC SSO guide.

An Azure app registration (also called an "Azure AD app", or an "Entra app" since Microsoft renamed Azure Active Directory to Microsoft Entra ID in 2023) is Microsoft's equivalent of a Google OAuth app. The Azure Portal and the Microsoft Entra admin centre show the same app registrations.

1 Register an App in Azure

  1. Go to entra.microsoft.com and sign in. (You can also reach the same app registrations from portal.azure.com through [Microsoft Entra ID] in the left sidebar.)
  2. Go to [Applications] → [App registrations] in the left sidebar.
  3. Click [+ New registration].
  4. Fill in the registration form:
    • • Name: "Tymeslot"
    • • Supported account types: select Accounts in any organizational directory and personal Microsoft accounts. This lets both personal Outlook.com accounts and work or school Microsoft 365 accounts connect.
    • • Redirect URI: choose Web from the platform dropdown, then enter https://yourdomain.com/auth/outlook/calendar/callback For Teams meeting creation, add a second Web redirect URI after registration (under [Authentication]): https://yourdomain.com/auth/teams/video/callback
  5. Click [Register]. You land on the app's Overview page.

Only need personal Outlook accounts?

If all your users have personal Microsoft accounts (Outlook.com, Hotmail, Live), you can select Personal Microsoft accounts only during registration. This setting decides who can connect, not what they can do afterwards: whether an account can host a Teams meeting depends on its licence.

2 Note Your Application ID

The Overview page opens straight after registration. Find these two values:

  • Application (client) ID: copy it; this is your OUTLOOK_CLIENT_ID.
  • Directory (tenant) ID: you do not set it anywhere. Tymeslot always uses Microsoft's common endpoint so both personal and organisational accounts can connect, and you cannot restrict it to a single directory.

3 Create a Client Secret

In the left sidebar of your app registration, go to [Certificates & secrets] → [New client secret].

  1. Description: "Tymeslot production", so you can identify it later
  2. Expires: 24 months is a reasonable choice. Set a reminder to replace it before it expires: once it does, every Outlook and Teams connection stops working
  3. Click [Add]. A new row appears in the secrets list.
  4. Copy the value from the Value column immediately. This is your OUTLOOK_CLIENT_SECRET.

The secret value is only visible once

Once you leave this page, the Value column shows only a truncated preview, and the full value cannot be recovered. If you forget to copy it, delete the secret and create a new one; this does not affect your app registration or permissions.

4 Add API Permissions

Go to [API permissions] → [Add a permission] → [Microsoft Graph] → [Delegated permissions]. Search for and add each of these:

  • User.Read

    Identifies the connected account during the calendar and Teams OAuth flow: Tymeslot reads the account's name and email to label the integration.

  • Calendars.ReadWrite

    Required for Outlook Calendar sync: reads existing events to check availability and creates events for new bookings. It also covers Microsoft Teams, because Tymeslot creates a Teams meeting as a calendar event with online meeting turned on.

OnlineMeetings.ReadWrite is not needed

Microsoft's documentation points at OnlineMeetings.ReadWrite for Teams meetings, but that permission belongs to the online meetings endpoint, which Tymeslot does not call. Adding it changes nothing, and in most tenants it turns a connection any user could make into one that waits on an administrator.

After adding all permissions, click [Grant admin consent for (your org name)] if you have admin rights. A green tick next to each permission confirms consent.

Not an admin?

If you do not have admin rights, you can still save the permissions. Both are permissions a user can consent to, so each user is prompted to grant them on their first sign-in. An administrator only has to step in where the organisation has turned off user consent for third-party apps, and then the same grant covers everyone.

5 Configure Environment Variables

Add the following to your Tymeslot environment and restart it.

# OAuth credentials (from Steps 2 and 3)
OUTLOOK_CLIENT_ID=your-application-client-id
OUTLOOK_CLIENT_SECRET=your-client-secret-value

# Random secret used to sign the OAuth state parameter
OUTLOOK_STATE_SECRET=your-random-32-char-secret

Generate a secure state secret with:

openssl rand -hex 32

Common Errors

Calendar sync fails with "Insufficient privileges"

The Calendars.ReadWrite permission is missing, or admin consent was not granted for organisational accounts. Return to [API permissions] in your app registration, confirm the permission is listed, and click [Grant admin consent].

Teams meeting creation fails

Teams meetings are created as calendar events, so Calendars.ReadWrite is the permission to check in the [API permissions] list; if the tenant column shows "Not granted", an Azure admin must click [Grant admin consent]. Where the permission is granted and the booking is still confirmed without a join link, the connected account itself cannot host a Teams meeting; see the Microsoft Teams guide.

"AADSTS50011: The redirect URI does not match"

The callback URL Tymeslot sent does not match the one you registered. Go to [Authentication] in your app registration and confirm the redirect URI there matches your domain exactly, including the https:// scheme and the /auth/outlook/calendar/callback path (or /auth/teams/video/callback for Teams).

"AADSTS700016: Application not found in directory"

The OUTLOOK_CLIENT_ID environment variable does not match the Application (client) ID of your registration. Copy the value again from the Overview page of your app registration.

❓ Frequently Asked Questions

Azure returns 'AADSTS50011: The reply URL specified in the request does not match'. Why?

The redirect URI registered in your Azure app must exactly match the URL Tymeslot sends during the OAuth flow. Common mismatches include a trailing slash ( /auth/outlook/calendar/callback/ vs /auth/outlook/calendar/callback ), using http:// in production instead of https://, or a domain mismatch (for example, after changing your domain without updating the Azure registration). Go to [Authentication] in your app registration and make sure the URI listed there is exactly https://yourdomain.com/auth/outlook/calendar/callback.

I'm getting 'Need admin approval' when signing in. What does that mean?

Your organisation's Microsoft Entra tenant requires admin consent before users can authorise new applications, so an administrator must grant consent for the app's permissions before anyone in the organisation can connect. The admin can do this by going to [API permissions] in your app registration and clicking [Grant admin consent for (your org name)]. Alternatively, send the admin the admin consent URL, which follows the pattern https://login.microsoftonline.com/{tenant-id}/adminconsent?client_id={client-id}.

What's the difference between 'Delegated' and 'Application' permissions in Azure?

Tymeslot uses Delegated permissions only. With delegated permissions, the app acts on behalf of the signed-in user: the user must consent, and the app can only reach what that user can reach. Application permissions are granted to the app itself, with no user involved, and are meant for background services. Both permissions described in this guide, User.Read and Calendars.ReadWrite, must be added as Delegated permissions.

Can I use the same Azure app registration for both personal (Outlook.com) and work (Microsoft 365) accounts?

Yes, provided you set Supported account types to Accounts in any organizational directory and personal Microsoft accounts during registration (or update it afterwards under [Authentication]). Tymeslot always authenticates against Microsoft's common endpoint, so with this setting both personal and organisational accounts can connect their calendars. Whether a given account can also host a Teams meeting depends on its licence, not on this setting.

My Azure app registration shows 'Unverified'. Is that a problem?

No. For a self-hosted Tymeslot instance, the "Unverified" label is expected. Microsoft shows it for apps that have not completed publisher verification, which requires a verified Microsoft Partner Network account. Users see an "unverified" notice on the consent screen the first time they connect, but they can still continue. Publisher verification is optional and matters mainly if users in other organisations will connect, since some tenants block unverified apps.

Verification Checklist

Confirm each of the following after restarting Tymeslot:
  • An Outlook Calendar connection option is visible under Dashboard → Integrations.
  • Clicking Connect on it opens Microsoft's sign-in page, then returns to Tymeslot without an error.
  • If using Teams: a Microsoft Teams option is visible in the video section of the same page, and a test booking produces a Teams link.

🔗 Related Articles

Read Google OAuth App Setup

Google OAuth App Setup

Set up a Google OAuth app in Google Cloud Console. One app powers Google Login, Calendar sync, and Meet rooms for Tymeslot. Covers API enabling and consent screen.

Read Generic SSO (OAuth / OIDC)

Generic SSO (OAuth / OIDC)

Connect any OAuth 2.0 / OpenID Connect identity provider for single sign-on. Supports Keycloak, Authentik, Lemonldap::NG, Okta, Azure AD, and more.