Office 365 Migration Using App-Only Authentication
App-only authentication allows EdbMails to connect to supported Microsoft 365 services by using an application identity instead of requiring an administrator to remain interactively signed in. The connection uses OAuth 2.0 and Microsoft Entra ID, with access controlled by the application permissions and administrator consent configured for the tenant.
This model is suitable for supported non-interactive migration connections and long-running migration jobs. It also avoids relying on legacy Basic Authentication. App-only authentication does not itself perform user Multifactor Authentication (MFA); however, administrator sign-in during application setup or consent can still be subject to the tenant's MFA and Conditional Access policies.
EdbMails supports app-based authentication for Microsoft 365 migration through automatic or manual Microsoft Entra application registration. The exact Microsoft 365 services and APIs used depend on the selected workload and the permissions documented for that EdbMails connection method.
What is App-only Authentication?
App-only authentication is an OAuth 2.0 authentication model in which an application authenticates with its own identity instead of acting on behalf of a signed-in user. The Microsoft Entra application is represented in the tenant by a service principal, and administrators grant the application the permissions required for the supported migration workload.
When EdbMails connects, Microsoft Entra ID validates the configured application identity and, when the configuration is valid, issues a time-limited access token. Microsoft 365 services evaluate that token and the application's approved permissions before allowing the requested operation.
For manual registration, the current EdbMails workflow uses application details such as the Tenant ID, Application (Client) ID, and client secret. These values must be protected and kept valid for the duration of the migration project.
App Registration Options in EdbMails
or the detailed procedurBefore EdbMails can use app-only authentication, a Microsoft Entra application must be available for the tenant. EdbMails provides automatic and manual registration options so administrators can choose the method that fits their tenant governance and migration requirements.
Automatic App Registration
Automatic App Registration reduces the number of manual configuration steps. A Microsoft 365 Global Administrator signs in, reviews the requested permissions, and grants consent so EdbMails can create and configure the required application for the supported connection workflow.
For the detailed procedure, see Automatic Registration.
Manual App Registration
Manual App Registration is useful when an organization wants to create and manage the Microsoft Entra application under its own administrative controls. Administrators configure the documented application permissions, grant administrator consent, create the required application credential, and enter the application details in EdbMails.
For the current permission and configuration steps, see Manual Registration of EdbMails in Microsoft Entra ID.
Benefits of App-only Authentication
For supported Microsoft 365 migration connections, app-only authentication provides several operational and security advantages:
- It does not require an interactive administrator sign-in for every token request after the application connection is configured.
- It avoids storing an administrator password as the application authentication method.
- Microsoft Entra ID issues time-limited access tokens at runtime.
- Application permissions and administrator consent are managed centrally in Microsoft Entra ID.
- It supports long-running and unattended migration workflows where supported by the selected EdbMails migration scenario.
- Administrators can review and revoke application access when the migration project is complete.
For manual registration, the configured client secret remains an application credential even though the access tokens are time-limited. The secret must therefore be stored securely and renewed before it expires if the migration project is still active.
App-Only Authentication vs. Delegated Authentication
| Feature | App-only authentication | Delegated authentication |
|---|---|---|
| Authentication identity | Application | Signed-in user |
| Interactive user sign-in | Not required for each client-credential token request after configuration | Required as part of the user authentication flow |
| MFA | No user MFA challenge occurs during client-credential authentication; administrator setup or consent can still be subject to tenant MFA policies | Can be subject to MFA during user sign-in |
| Permissions | Application permissions approved for the app | Delegated permissions used in the context of the signed-in user |
| Credentials | Application ID plus the configured application credential; the current EdbMails manual workflow uses a client secret | User authentication context and delegated access |
| Typical use | Supported non-interactive and long-running migration connections | Interactive user-based access |
How App-only Authentication Works
After the Microsoft Entra application is configured and the required permissions are granted, EdbMails can request OAuth 2.0 access tokens for supported migration operations.
Step 1: Configure the application and grant consent
Configure the application using the EdbMails automatic or manual registration workflow. Review the documented permissions and grant administrator consent for the tenant.
Step 2: Validate the application details
EdbMails uses the configured tenant and application details to request access. For manual registration, verify the Tenant ID, Application (Client) ID, client secret, permissions, and consent status.
Step 3: Request an OAuth access token
Microsoft Entra ID validates the application identity and credential. When the request is valid, it issues a time-limited access token containing the approved application access for the requested resource.
Step 4: Authorize supported Microsoft 365 requests
EdbMails presents the token when it performs supported operations. The relevant Microsoft 365 service validates the token and checks whether the application has the required permissions.
Step 5: Continue the migration while the configuration remains valid
EdbMails can request a new access token when required while the application credential, permissions, tenant configuration, and administrator consent remain valid. If the client secret expires or the application permissions change, the connection may need to be updated before migration can continue.
Prerequisites for App-Only Authentication
Before configuring app-only authentication in EdbMails, verify the requirements for the selected connection method and migration workload.
- An active Microsoft 365 tenant for the source or destination connection.
- A supported version of EdbMails.
- A Microsoft Entra application configured through Automatic App Registration or Manual App Registration.
- The application permissions documented by EdbMails for the selected workload.
- Administrator consent for the required application permissions.
- For manual registration, a valid Tenant ID, Application (Client) ID, and client secret.
- A client secret whose expiration date extends through the planned migration window.
- Network access to the Microsoft identity and Microsoft 365 endpoints required by the connection.
- Source and target application configuration checked separately when both tenants are involved.
Before loading mailboxes or starting a production migration, validate the source and target connections in EdbMails and confirm that the required application permissions are available for each side.
Common Migration Scenarios in App-Only Authentication
App-only authentication can be used for supported Microsoft 365 migration scenarios that require a non-interactive application connection. The exact operations available depend on the selected workload and the permissions granted to the application.
Exchange Online Mailbox Migration
EdbMails can use the configured application identity to perform supported mailbox migration operations without requiring an administrator to sign in for each authentication request.
Tenant-to-Tenant Migration
For tenant-to-tenant migration, validate the source and destination applications, permissions, and consent independently. Do not assume that an application configured in one tenant automatically authorizes access to the other tenant.
Shared Mailbox Migration
Shared mailbox access depends on the selected migration operation and the permissions granted to the application. Separate shared mailbox user credentials are not used as the app-only authentication identity.
Public Folder Migration
For supported public folder migration workflows, app-based authentication can help avoid repeated interactive administrator sign-ins during extended migration runs. Confirm the documented permissions for the selected source and destination before starting.
Scheduled or Long-Running Migration Jobs
Once the application connection is configured, client-credential authentication does not require an administrator to remain interactively signed in for each token request. The application credential and permissions must remain valid throughout the migration.
Common Issues and Troubleshooting
If app-only authentication cannot connect to Microsoft 365, check the application identity, credential, permissions, consent, tenant selection, and source/target configuration before changing the migration settings.
Issue Likely cause What to check Insufficient application permissions One or more documented application permissions are missing Compare the Microsoft Entra permissions with the current EdbMails registration guide and grant administrator consent after adding required permissions. Administrator consent not granted Permissions were added but tenant-wide administrator consent was not completed Review the API permissions page in Microsoft Entra ID and complete the required consent process. Authentication fails Tenant ID, Application ID, application credential, or tenant selection is incorrect Verify the Tenant ID and Application (Client) ID and confirm that the application belongs to the intended tenant. Client secret expired or invalid The configured manual-registration secret has expired, was revoked, or the wrong secret value was entered Create or use a valid client secret according to the EdbMails manual-registration procedure and update the connection securely. Permission changes are not reflected Permissions changed but required administrator consent was not refreshed Review the updated permissions, grant consent where required, and reconnect from EdbMails. Wrong source or target app configuration Credentials from one tenant were used for the other tenant Verify source and destination Tenant IDs, Application IDs, credentials, and consent separately. Mailbox or resource discovery fails The application can authenticate but does not have the permissions required for the selected workload Confirm the current EdbMails permissions for that workload instead of assuming the same permission set applies to every Microsoft 365 service.
Security Considerations
- Protect the Tenant ID, Application ID, and especially the client secret used for manual registration.
- Do not place client secrets in public documentation, scripts, tickets, or screenshots.
- Grant only the permissions documented by EdbMails for the selected workload.
- Review the application's consent and credential expiration before each migration phase.
- Use separate source and destination configuration where the migration requires access to different tenants.
- Review Microsoft Entra audit information when investigating authentication or consent changes.
- Microsoft 365 authentication and service APIs can change over time. Use the current EdbMails and Microsoft guidance rather than assuming one API or permission model applies to every workload.
Best Practices
- Use Modern Authentication for Microsoft 365 migration connections and avoid legacy Basic Authentication.
- Choose automatic or manual app registration based on the organization's administration and governance requirements.
- For manual registration, record the client secret expiration date and renew the credential before it expires when the migration is still active.
- Review application permissions periodically and remove access that is no longer required.
- Validate both source and target connections before loading mailboxes or beginning migration.
- Perform a pilot migration with representative mailboxes before a larger production batch.
- Keep the application registration details for the source and destination clearly separated.
- Remove or revoke migration applications and credentials after the project if they are no longer required by the organization.
Conclusion
App-only authentication is a suitable approach for supported non-interactive Microsoft 365 migration connections because it uses an application identity and OAuth 2.0 rather than requiring an administrator to remain signed in for each authentication request.
EdbMails supports automatic and manual Microsoft Entra application registration. Before starting migration, verify the documented permissions, administrator consent, source and destination configuration, and any application credential expiration dates that apply to the selected connection method.
Frequently Asked Questions
What is the difference between app-only and delegated authentication?
App-only authentication uses the Microsoft Entra application identity and application permissions. Delegated authentication operates in the context of a signed-in user and uses delegated permissions associated with that user session.
Do I need Global Administrator access for EdbMails app registration?
EdbMails automatic registration currently requires Global Administrator access for the documented setup and consent workflow. For manual registration, follow the current EdbMails procedure for the administrator role and consent requirements instead of assuming the same role requirement applies to every Microsoft Entra operation.
What information is required for manual app registration in EdbMails?
The current EdbMails manual-registration workflow uses the Microsoft Entra Tenant ID, Application (Client) ID, a valid client secret, the required application permissions, and administrator consent. Follow the current manual-registration guide for the exact workload-specific permissions.
What happens if the client secret expires during migration?
An expired or invalid client secret can prevent the application from obtaining new access tokens. Renew or replace the credential according to the EdbMails manual-registration process, update the connection, and validate authentication before continuing the migration.
Should source and target tenants use separate app configuration?
For migrations that connect to different Microsoft 365 tenants, verify the source and target application details, permissions, and consent independently. An application configured in one tenant does not automatically provide access to another tenant.
