Same login works in one app but fails in another: how to troubleshoot

TL;DR — If the same sign-in works for one application but not another, the most common reason is that the second app is using a different identity provider or a different sign-in configuration behind the scenes. Start by checking which sign-in page each app sends you to and whether your account is assigned to that specific app; those two checks solve most cases. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon. You open App A, click Sign in with Google or Sign in with Microsoft, and you are in immediately. Then you open App B from the same agency, use what looks like the same sign-in button and the same email address, and get bounced back to the login page, an "access denied" message, or a blank error after the redirect. Your browser already remembers your session for one app, so it feels like the second app should just work too — but it does not.

Symptoms

• You can sign in to one application, but another application from the same agency fails.
• The failing app shows one of these messages:
  • "Access denied"
  • "You are not assigned to this application"
  • "Invalid redirect_uri"
  • "AADSTS50011: The redirect URI specified in the request does not match"
  • "redirect_uri_mismatch"
  • "Unauthorized"
  • "Your session has expired"
  • "Cookies are disabled or blocked"
• After entering credentials, you are redirected back to the app and then immediately back to the sign-in page again.
• One app sends you to a sign-in page on one domain, while the other app sends you to a different domain.
• In browser developer tools (the browser's built-in page inspector), the failing app may show:
  • HTTP 401 Unauthorized
  • HTTP 403 Forbidden
  • HTTP 302 redirect loops between the app and the login provider
• In app or auth logs, you may see lines like:

redirect_uri_mismatch
invalid_client
user_not_assigned
token audience invalid
nonce mismatch
state mismatch
cookie not found
clock skew too large

Likely causes

Step-by-step diagnosis

1. Check whether both apps use the same login provider
   Action: Open each app, click Sign in, and look at the browser address bar on the login page.
   What confirms the problem: App A sends you to one domain, such as accounts.google.com, login.microsoftonline.com, or auth.yourcompany.com, while App B sends you to a different one or to a different tenant/company-branded page.
   Jump to: Fixes → Different identity provider or tenant.

2. Try the failing app in a private/incognito window
   Action: Open a private/incognito window, go directly to the failing app, and sign in once.
   What confirms the problem: The app works in private/incognito but not in your normal browser window. That usually means a cookie, saved session, or extension is interfering.
   Jump to: Fixes → Browser cookies are blocked or stale.

3. Check whether your account is assigned to the failing app
   Action: In your identity provider's dashboard (for example, Microsoft Entra/Azure AD, Okta, Google Cloud Identity), open the failing application and view its user assignments. Typical path is Applications/Enterprise apps → [failing app] → Users and groups or Applications → Assignments.
   What confirms the problem: Your email or group is missing from the app assignment list, or the app is set to require assignment before sign-in.
   Jump to: Fixes → User is not assigned to the application.

4. Compare the app URL to the configured redirect/callback URL
   Action: In the identity provider dashboard, open the failing app's login settings. Look for Redirect URIs, Callback URLs, or Reply URLs. Compare them to the exact app URL you are using, including https, subdomain, and path.
   What confirms the problem: The configured URL does not exactly match the app's real sign-in callback, or the error page shows redirect_uri_mismatch or AADSTS50011.
   Jump to: Fixes → Redirect URL mismatch.

5. Check whether the app expects a role, group, or email domain you do not have
   Action: If you have access to the app admin area, open its auth or audit logs. If not, send the exact timestamp and your email to support and ask them to check for claim/role errors.
   What confirms the problem: Logs show errors like user_not_assigned, missing role, invalid audience, group claim missing, or the app only allows @company.com but you signed in with another domain.
   Jump to: Fixes → Missing role, group, or claim.

6. Check device time and session expiry issues
   Action: On your computer, enable automatic date/time and timezone, then fully close the browser and try again.
   What confirms the problem: After correcting the clock or clearing the old session, sign-in starts working, or logs show clock skew, token expired, or nonce/state mismatch.
   Jump to: Fixes → Clock or session mismatch.

Fixes

Different identity provider or tenant

If the apps send you to different login domains, they are not actually sharing the same sign-in system.

What to do:

1. Use the sign-in method expected by the failing app. If App B sends you to Microsoft, do not use a Google-only account unless that Microsoft tenant is set up to accept it.
2. Ask the agency or your admin which identity provider and tenant the failing app uses.
3. If you are the admin, align the app to the correct provider in the app settings or identity provider dashboard.

Typical values to compare:

App A login page: https://login.microsoftonline.com/<tenant-a>/...
App B login page: https://login.microsoftonline.com/<tenant-b>/...
App B custom auth: https://auth.example.com/...

If you manage the app config, the setting often looks like this:

{
  "issuer": "https://login.microsoftonline.com/<tenant-id>/v2.0",
  "client_id": "<app-client-id>",
  "authority": "https://login.microsoftonline.com/<tenant-id>"
}

Verify it worked: Start sign-in again and confirm both apps now send you to the same expected login domain/tenant.

User is not assigned to the application

Some identity providers allow sign-in only for users or groups explicitly assigned to that app.

What to do in the dashboard:

• Open Applications/Enterprise apps → [failing app] → Users and groups.
• Click Add user/group.
• Select your user or a group you belong to.
• Save.

If your provider supports group-based assignment, add a group instead of individual users to avoid repeating this later.

Verify it worked: Sign in again; the error "You are not assigned to this application" should be gone.

Redirect URL mismatch

The login provider will reject the sign-in if the callback URL does not exactly match what is configured.

What to do:

• In the identity provider dashboard, open the failing app's Redirect URIs / Callback URLs / Reply URLs.
• Add the exact callback used by the app. Common examples:

https://app.example.com/auth/callback
https://app.example.com/oauth/callback
https://client.example.com/signin-oidc

• Save the change.

If you manage the app config, confirm the app is sending the same redirect URL:

{
  "redirect_uri": "https://app.example.com/auth/callback"
}

Common mismatch examples:

Configured: https://app.example.com/auth/callback
Actual:     https://www.app.example.com/auth/callback

Configured: http://app.example.com/auth/callback
Actual:     https://app.example.com/auth/callback

Verify it worked: Retry sign-in; redirect_uri_mismatch or AADSTS50011 should no longer appear.

Browser cookies are blocked or stale

Modern login flows often depend on cookies across redirects. A stale cookie, privacy extension, or blocked third-party cookie can break one app while another still works.

What to do in the browser:

1. Open the failing app in a private/incognito window.
2. If that works, clear cookies for the app and login provider domains in your normal browser.
3. Temporarily disable privacy/ad-blocking extensions for the app domain.
4. If your browser blocks third-party cookies, allow cookies for the app and auth domains.

Typical domains to clear:

app.example.com
auth.example.com
login.microsoftonline.com
accounts.google.com

Verify it worked: In a normal browser window, sign in once without being looped back to the login page.

Missing role, group, or claim

The login itself may succeed, but the app rejects you because the token does not include the role, group, or email domain it expects.

What to do:

• In the identity provider dashboard, open the app's token/claim settings and confirm the required fields are sent.
• In the app admin area, check which roles or groups are allowed.
• Add your user to the required group or role.

Examples of expected values:

Allowed email domain: @client.com
Required role: admin
Required group: app-users
Expected audience (aud): <app-client-id>

If you manage the app config, it may look like:

{
  "allowed_domains": ["client.com"],
  "required_role": "app-users"
}

Verify it worked: The app opens after sign-in instead of showing 403 Forbidden or an access denied page.

Clock or session mismatch

If your device time is wrong, or the browser is holding a broken old session, the app can reject a valid login token.

What to do:

• Turn on automatic date, time, and timezone in your operating system settings.
• Fully quit the browser and reopen it.
• If needed, clear cookies for the app and auth domains, then sign in again.

If you are an admin checking logs, these messages point here:

token expired
clock skew too large
nonce mismatch
state mismatch

Verify it worked: After correcting time and starting a fresh browser session, the sign-in completes normally.

Prevention

• Document the identity provider and tenant per app. Keep a simple table in your internal docs:

App A -> Microsoft Entra tenant X -> https://login.microsoftonline.com/<tenant-x>
App B -> Auth provider Y -> https://auth.example.com

• Pin redirect URLs in deployment checklists and CI (continuous integration, automated checks). Store allowed callback URLs in config and review them on every domain change:

{
  "production_redirect_uris": [
    "https://app.example.com/auth/callback",
    "https://client.example.com/signin-oidc"
  ]
}

• Use group-based app assignment instead of one-off user assignment. Create a group such as app-users and assign the app to that group, then add/remove users from the group only.
• Add auth error monitoring for the exact failure strings. Alert on spikes in these log messages:

redirect_uri_mismatch
AADSTS50011
user_not_assigned
invalid audience
nonce mismatch
state mismatch

• Test sign-in in a clean browser profile before releases. Add one release step: open the app in a private/incognito window and complete a full login flow.
• Keep app URLs and custom domains stable. If you change app.example.com to www.app.example.com, update the identity provider callback URLs in the same change window, not later.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.