User is authenticated but not connected.

Question

User is authenticated but not connected.

Jan Sterba 0

I have created an app registratio and configured it with required scopes to access emails over IMAP and SMTP. CleanShot 2025-09-30 at 23.49.38@2x

I tested the app and oauth flow with my outlook account and everything seems to work fine.

When a client uses the oauth flow to connect their azure managed office 365 account the generated token do not work when accessing their emails via IMAP.

We can connect and authenticate with IMAP but when we actually try to select a folder or fetch a list of folders we get: "User is authenticated but not connected."

How can we fix this? It seems like some configuration on the user tenant side more than on our side. Please advise.

0 comments

1 answer

Your answer

Answer 1

Anonymous

Hi Jan,

Thank you for posting your query on Microsoft Q&A.

The error “User is authenticated but not connected” when accessing Office 365/Exchange mail over IMAP and OAuth often indicates an issue on the tenant or mailbox configuration. While your app registration and OAuth flow with Outlook accounts may be correct, connecting to Azure-managed Office 365 mailboxes can require tenant-level changes.

Remediation Steps:

IMAP Enablement
- Ensure IMAP is enabled for the mailbox user on the target tenant. Tenant admins can check and enable this in Exchange Online admin center under mailbox features.
1. API Permissions
  - Check your Azure app registration includes IMAP.AccessAsUser.All (Delegated) and the required SMTP.Send and Mail permissions, as shown in your screenshot.
    - Confirm the permissions have been granted consent (admin consent may be needed in some tenants, even if not indicated in portal).
    1. Tenant Consent/Approval
      - For delegated permissions, organizational users may need tenant admin consent. If users get “need admin approval” errors, the tenant admin should grant access to the required delegated scopes for your app.
      1. Conditional Access/Policies
        
        Review any conditional access policies or security restrictions on the tenant, which may block access for IMAP or specific clients. Blocking legacy authentication can affect certain IMAP flows, even for OAuth.
        
        Session/Rate Limits
        
        Office 365 IMAP implementation can lock out users if too many sessions are opened/closed rapidly. Wait a few minutes, disable and re-enable IMAP as a test, and avoid frequent reconnects during troubleshooting.
        
        Token Scope/Resource
        
        Ensure you use correct scope/resource in OAuth requests (e.g., use IMAP.AccessAsUser.All with https://outlook.office.com or https://graph.microsoft.com as appropriate).
        
        Mailbox Licensing
        
        Verify the mailbox account being accessed is licensed. Unlicensed/shared mailboxes or service accounts may not authenticate successfully through OAuth IMAP.
        
        Firewall/Network
        
        Confirm that IMAP (port 993) and SMTP traffic is allowed to Microsoft 365 endpoints from the client network.

Please refer to:

Enable and troubleshoot IMAP/SMTP with OAuth for Office 365 learn.microsoft

Please "Accept as Answer" if the answer provided is useful, so that you can help others in the community looking for remediation for similar issues.

Jan Sterba 0 Reputation points

2025-10-03T20:03:32.7333333+00:00
Hi,

thank you for the insight. On the app side when generating the authorize request URL we only include the scopes below. Is that correct or should more scopes be included?

offline_access https://outlook.office.com/IMAP.AccessAsUser.All https://outlook.office.com/SMTP.Send openid profile
Jan Sterba 0 Reputation points

2025-10-03T20:07:54.6133333+00:00

one more question: could Security defaults be preventing IMAP access?
Anonymous

2025-10-08T08:22:56.2266667+00:00
Hi Jan,

Thank you for the response.

The scopes you are including in the authorization request URL are mostly correct for accessing Office 365 mail via IMAP and SMTP, but some additional considerations are necessary:

Scope Details:

offline_access: Allows refresh tokens for ongoing access, which is recommended if your app needs persistent access.

https://outlook.office.com/IMAP.AccessAsUser.All: Correct for IMAP access. Ensure this permission is granted via admin consent in Azure AD.

https://outlook.office.com/SMTP.Send: Correct for SMTP sending. Again, ensure it has been consented and granted.

openid & profile: These are standard OIDC scopes for user authentication purposes, allowing you to retrieve user identity info. They are useful but not strictly required for IMAP access unless your app also performs sign-in.

Additional Recommendations:

Admin Consent: Verify that all these scopes, especially IMAP.AccessAsUser.All, have been granted admin consent in your tenant. Without admin consent, OAuth tokens with these scopes may not work fully.

Scope Inclusion: When generating the authorization URL, include all necessary scopes that you want the token to have. For mail access, ensure scopes like IMAP.AccessAsUser.All and SMTP.Send are included.

Azure AD Configuration: Confirm your app registration in Azure AD has these API permissions assigned and granted consent.

Could Security Defaults Block IMAP Access?

Yes, Security Defaults can restrict legacy protocols or protocols like IMAP if they are considered insecure.

To verify, check in Azure AD > Security > Conditional Access policies and in the Authentication methods policies to see if IMAP or legacy protocols are restricted.

References:

Configure OAuth for IMAP and SMTP

Microsoft Graph permissions reference

Configure Security Defaults for Microsoft Entra ID - Microsoft Entra | Microsoft Learn

Please "Accept as Answer" if the answer provided is useful, so that you can help others in the community looking for remediation for similar issues.
Jan Sterba 0 Reputation points

2025-10-08T12:55:08.19+00:00
Hi,

thank you this is very helpful.
I have one more question about the OAuth flow.

user clicks Login with Microsoft in our app

authorize URL is generated and user is redirected to given URL

user logs in with their email account, but is prompted that admin consent is required for given scopes

user also has admin credentials so they click Sign in with another account and enter tenant admin credentials

user approves OAuth request and is redirected back to our app

the app gets tokens via the received code

the tokens are for the tenant Admin account email but IMAP login is possible with regular user email as well

Is this flow as expected. What worries me that the oauth response contains email of the Admin user not the regualar email account user, but it is possible to IMAP authenticate, but IMAP fetch/list fails with Authenticated-not-connected.
Anonymous

2025-10-09T08:25:34.89+00:00
Hi Jan,

Thank you for your follow-up question on Microsoft Q&A.

Regarding the described OAuth flow:

When a user selects "Login with Microsoft", your app generates an authorize URL and redirects the user for authentication.

If the scopes require admin consent, the user is prompted to sign in with an admin account.

Once the tenant admin logs in and approves the request, your app receives tokens associated with the admin account's email.

You then use these tokens to attempt IMAP login with a regular user's email; authentication may succeed, but fetching folders via IMAP fails with "Authenticated-not-connected".

Is this expected behavior? Yes, this is expected in Microsoft Entra ID. When an admin provides consent for delegated permissions on behalf of the organization, the initial tokens are associated with the admin’s identity as the consenting principal. This enables tenant-wide permissions for the application, but does not automatically issue tokens for every user in the tenant. IMAP authentication for regular users can succeed if their mailbox and protocol access are enabled and the app’s permissions are granted tenant-wide. However, issues like "Authenticated-not-connected" generally indicate the mailbox is either not enabled for IMAP or the delegated permissions for the specific user context are missing or misconfigured.

Clarifying Token and User Context:

The OAuth token email will reflect the admin that granted consent not the regular user, when tenant-wide consent is performed.

The app must obtain an access token for each specific user when performing actions on that user's mailbox via IMAP; simply having admin consent and an admin token is not sufficient to access other users' mailboxes.

For proper delegated access, after admin consent, initiate the OAuth flow with the regular user's credentials so that the returned token is scoped to the regular user's mailbox.

Recommendations:

After tenant admin has granted consent, have each regular user log in through your app so their mailbox-specific OAuth token is issued.

Check that IMAP is enabled for the user’s mailbox in Exchange admin center or with PowerShell.

Ensure app registration has correct delegated permissions (IMAP.AccessAsUser.All), and consent is applied tenant-wide.

If you use only the admin token to access a regular mailbox, it may authenticate but cannot fetch data without a user-specific token; hence, IMAP fetch/list operations fail ("Authenticated-not-connected").

For additional reference:

Admin consent workflow in Microsoft identity platform

Authenticate IMAP using OAuth in Exchange Online

Enable or disable POP3, IMAP, MAPI, Outlook Web App or ActiveSync in Microsoft 365 - Exchange | Microsoft Learn

Please click "Accept as Answer" if this resolves your issue. This will help others with a similar problem find the solution.s
Jan Sterba 0 Reputation points

2025-10-09T10:14:41.35+00:00

Hi,

thank you that is most helpful! I feel like we are getting somewhere!
We have completed the admin consent flow, but when a regular user tries to complete the OAuth Flow we are still getting Approval required and regular user is not able to complete the OAuth flow.
What could be causing this? Where should we check that admin consent has been properly granted?
Thank you.
Anonymous

2025-10-10T09:29:01.25+00:00
Hi Jan,

Thank you for posting your query on Microsoft Q&A.

Based on the conversation and your latest issue, where regular users are still seeing "Approval required" with the OAuth flow even after completing admin consent.

Why Are Regular Users Seeing "Approval Required" After Admin Consent?

Common Cause: Admin consent may not have been properly granted tenant-wide for all required permissions and scopes. If consent was only granted for the admin user, or if not all requested permissions are approved at the organizational level, regular users will continue to see the approval prompt.

Permission Scope: Make sure that the application has been granted admin consent "on behalf of the organization" for all required API permissions (typically including IMAP.AccessAsUser.All, offline_access, User.Read, etc.) as "delegated permissions." Application permissions must match exactly what is being requested during the OAuth flow.

Steps to Troubleshoot and Resolve:

1. Explicitly Grant Admin Consent Organization-Wide

In the Microsoft Entra admin center, ensure an admin uses the consent screen and checks the option to grant consent for the entire organization—not just their own account.

You can also use the admin consent endpoint directly:

https://login.microsoftonline.com/{tenant_id}/adminconsent?client_id={client_id}

Confirm the admin completes the consent screen to cover all users, not just one user.

2. Verify Permissions in Entra ID

Go to the Entra admin center: Enterprise Applications > Your App > Permissions.

Check that all the permissions needed by your app are granted, and that none are "pending admin consent."

If the status shows "Needs admin approval" for any permission, the consent must be re-granted.

3. User Consent Policy and Assignment

Check if user consent is disabled or restricted in Org Settings > User consent to apps or under Enterprise Applications > User settings.

If an app is set to require user assignment, make sure the user is assigned to that app.

4. Admin Consent Workflow

If the admin consent workflow is enabled, users will be able to request admin approval directly, and admins receive requests as notifications. Make sure the workflow is configured and reviewers are defined if you use this feature.

Reference Documentation:

Grant tenant-wide admin consent in Entra ID learn.microsoft

Overview of user and admin consent - Microsoft Entra ID learn.microsoft

Authenticate an IMAP, POP, or SMTP connection using OAuth learn.microsoft

Please re-validate the admin consent by reviewing the Entra admin portal, ensuring all required permissions are granted for the entire tenant, and check user assignment settings. Once completed, regular users should no longer be prompted for approval.

Please click "Accept as Answer" if this resolves your issue. This will help others with similar questions find a solution.