remix-auth-microsoft is a dedicated strategy for remix-auth that enables authentication against Microsoft Active Directory (work/school accounts) and personal Microsoft accounts (Skype, Xbox, Outlook.com). It extends remix-auth-oauth2 and simplifies the integration of Microsoft's OAuth 2.0 flow into Remix applications. The current stable version is 3.0.1, with major version releases often correlating with updates to its underlying remix-auth and remix-auth-oauth2 dependencies, alongside patch releases for bug fixes. Key differentiators include its tight integration with the Remix ecosystem via remix-auth, support for both Node.js and Cloudflare runtimes, and explicit guidance for multi-tenant and single-tenant configurations. It handles the intricacies of Microsoft's authentication endpoints, abstracting much of the OAuth 2.0 implementation details for developers, making it easier to implement secure Microsoft authentication flows in Remix applications.
npm install remix-auth-microsoftVerified import paths — ran on the pinned version, not inferred.
Demonstrates how to set up the MicrosoftStrategy with Remix Auth, including environment variable usage for credentials, recommended scopes, and a basic user resolution logic. It also includes an example of an authenticator instance and how to use it with the strategy.
Update `remix-auth` and `remix-auth-oauth2` to their latest major versions. If your MicrosoftStrategy configuration previously relied on a default `prompt` behavior, you must now explicitly set `prompt: 'select_account'` (or 'login', 'consent', etc.) in the strategy options.
Review your strategy configuration against the v2.0.0 documentation or examples to ensure all variable names are updated, e.g., to align with 'clientId', 'clientSecret', 'redirectURI', 'tenantId'.
Always use a robust, immutable identifier like the 'id' from the user profile (which maps to the 'sub' claim in the ID token) or the 'oid' claim for organizational IDs, to identify and retrieve users from your database.
Minimize the data stored directly in the session. Consider storing only a user ID in the session and fetching full user details from a database on each request. If storing tokens, only store what's absolutely necessary (e.g., refresh token for renewal) and keep other data external.
Ensure `tenantId: 'YOUR_DIRECTORY_TENANT_ID'` is set in your `MicrosoftStrategy` options when you intend to limit access to a single organization. Without it, the application might default to multi-tenant behavior if configured as such in Azure AD.
Ensure all required API permissions are configured in your Azure App Registration (API permissions blade). For organizational accounts, an administrator might need to grant tenant-wide consent. For personal accounts, the user needs to consent during the login flow.
Verify that the `redirectURI` in your `MicrosoftStrategy` options (e.g., `http://localhost:3000/auth/microsoft/callback`) is identical to an entry in the 'Authentication' blade -> 'Redirect URIs' section of your Azure App Registration. Include scheme (http/https) and path.
Go to your Azure App Registration -> 'Certificates & secrets' blade. Ensure you have an active client secret, copy its 'Value' (not 'Secret ID'), and update the `clientSecret` in your `MicrosoftStrategy` configuration.
Ensure `authenticator.use()` for `MicrosoftStrategy` is called only once. If you need multiple Microsoft strategies, provide a unique second argument to `authenticator.use(strategy, 'unique-name')` for each instance.