.NET Core Web API集成Teams会议：无需用户名密码流通过Graph API创建会议及生成链接的技术咨询

Great questions—let's break down the answers clearly for your .NET Core Web API scenario:

1. Can the Client Credentials Token Be Used to Generate Teams Meeting Links? #

Yes, but there are a couple of key conditions to meet first:

• Your Azure AD application must have the application-level Calendars.ReadWrite permission granted (this requires admin consent from your tenant).
• The token obtained via AcquireTokenForClient with the https://graph.microsoft.com/.default scope will include all application permissions assigned to your app, so as long as Calendars.ReadWrite is present, it's valid for creating calendar events with Teams meeting links.

When making the Graph API call to https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/calendar/events, you need to explicitly enable the Teams meeting by including these properties in your event payload:

• Set isOnlineMeeting to true
• Set onlineMeetingProvider to teamsForBusiness

Here's a quick code example to illustrate this:

// Initialize Graph Client with client credentials auth
var graphClient = new GraphServiceClient(new DelegateAuthenticationProvider(async (requestMessage) =>
{
    string[] scopes = new string[] { "https://graph.microsoft.com/.default" };
    var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();
    requestMessage.Headers.Authorization = new AuthenticationHeaderValue("Bearer", result.AccessToken);
}));

// Create the event with Teams meeting enabled
var teamsMeetingEvent = new Event
{
    Subject = "Project Kickoff",
    Start = new DateTimeTimeZone { DateTime = "2024-05-25T09:00:00", TimeZone = "Eastern Standard Time" },
    End = new DateTimeTimeZone { DateTime = "2024-05-25T10:30:00", TimeZone = "Eastern Standard Time" },
    IsOnlineMeeting = true,
    OnlineMeetingProvider = OnlineMeetingProviderType.TeamsForBusiness,
    Attendees = new List<Attendee>
    {
        new Attendee
        {
            EmailAddress = new EmailAddress { Address = "john.doe@example.com", Name = "John Doe" },
            Type = AttendeeType.Required
        }
    }
};

// Add the event to the specified user's calendar
await graphClient.Users["user-upn-or-id"].Calendar.Events.Request().AddAsync(teamsMeetingEvent);

2. Recommended Alternatives to Username-Password Flow #

You're right to move away from the username-password flow—it's insecure (exposes user credentials) and doesn't support modern auth features like MFA. Here are the supported, secure alternatives:

a. Client Credentials Flow (App-Only) #

This is exactly the flow you're currently testing! It's perfect for background services or daemons where there's no user interaction. Use this when you need to create meetings on behalf of a specific user (like a service account) without requiring anyone to sign in. Just remember you need admin consent for the application permissions.

b. Authorization Code Flow (Delegated) #

Ideal for web apps where end-users sign in to create meetings on their own calendar. This flow uses delegated permissions (e.g., Calendars.ReadWrite delegated), which usually don't require admin consent (depending on your tenant's settings). The steps are:

• Redirect the user to Azure AD's login page to get an authorization code
• Exchange that code for an access token (and refresh token)
• Use the access token to call Graph API on the user's behalf

c. On-Behalf-Of Flow (Delegated) #

If your Web API is being called by another client app (like a React frontend), use this flow to act on behalf of the authenticated user. The client app sends its own access token to your API, which you then exchange for a token that lets you call Graph API to create the meeting.

All three of these flows follow Microsoft's security best practices and support MFA, making them far more robust than the username-password flow.

内容的提问来源于stack exchange，提问作者Mayur2402