A Real Sign-In Page Can Still Be a Trap: Check App Permissions Before You Click Allow

A shared document, calendar tool, file converter, or AI service asks you to continue with Google or Microsoft. The sign-in page looks normal because it may be completely real. You sign in, see the familiar account design, and reach a screen showing app permissions that could let the service view or manage parts of your account.

Those permissions deserve a separate decision.

In a consent-phishing attack, the criminal may not need to imitate the sign-in provider or steal your password. As Microsoft's explanation of consent phishing describes, a malicious app can use a legitimate identity system and ask the user to grant it access. If the user approves the request, the app may receive a valid token with the permissions shown on the screen.

A real sign-in page can confirm where you are signing in, but it does not establish that the requesting app is trustworthy or needs the access it wants. The permissions screen is a security decision, not routine fine print.

Key Takeaways

• Signing in and granting permissions are two different decisions.

• A real Google or Microsoft sign-in page does not vouch for the outside app requesting access. Verify the app and developer as well as the provider.

• Compare every requested permission with the specific job you expect the app to perform.

• A verified publisher is a useful identity signal, not a guarantee of safety or a judgment that its permissions fit your task.

• MFA remains important, but it cannot decide whether you should authorize an app.

• If you already approved a questionable app, revoke its access first and then investigate what else may have happened.

Before you click Allow: a quick permissions check

You do not need to become an OAuth expert. You need a short sequence that interrupts the automatic click. Use Start, Name, Scope, Match, and Exit: did you start the task, do you recognize the app and developer, what can it do, does that access fit the feature, and can you cancel if an answer is unclear?

Confirm the task and identify the app

Ask why the prompt appeared. Did you deliberately open the service and choose to connect your account, or did an unsolicited message send you there? A request can still be fraudulent when it appears to come from a colleague. A familiar display name, logo or account design does not establish who operates the app receiving access.

Read the app name and publisher information on the provider's screen. Do both match the service you intended to use? If the app claims to come from your employer, school, bank or software provider, confirm that relationship independently. Do not try to resolve a mismatch by trusting the same message that created it.

The FTC's phishing guidance recommends reaching an organization through contact information or a site you already know is real. Open the service separately from a bookmark or typed address and check its official documentation for the integration. If a coworker supposedly sent a document, contact that person through a known channel and ask what they intended to share.

Translate the permissions into actions

Expand the details instead of deciding from the button label. Replace technical terms with verbs: what can the app read, copy, create, change, delete or send? Can it act as you? Can it keep access when you are not present? Does the request apply to one selected item or an entire service?

Compare that authority with the action you chose. A calendar scheduling feature may need to create appointments; that does not explain why it also wants to manage your mailbox. A one-time document task deserves a clear explanation if it requests access to a broad collection of files. One reasonable permission does not justify the rest of a bundle.

If you cannot tell what a permission allows, consult the provider's explanation before deciding. Do not guess that “read” is harmless or that “manage” means only the single file currently on screen. Your decision should cover the full request, including background access, rather than the most reassuring part of it.

Look for a narrower route and stop at administrator consent

The task may not require a broad account connection. You might be able to upload one file, share one folder or export a calendar item. Those alternatives still disclose the material you submit, so remove unnecessary private information and use a service you have independently checked. A smaller disclosure is useful only when it suits the task and recipient.

If the provider offers granular choices, select only the resources the feature needs. If the service refuses to explain why it needs more, cancel and look for another route. You are not required to approve extra access merely to avoid another setup step.

A prompt for administrator approval is a separate decision that may involve organization-wide access or permissions ordinary users cannot grant. Do not forward an administrator-consent link with a note saying, “Please approve this so I can continue.” Send the app name, developer, business purpose, requested access and official documentation to IT or security through the established review process.

Cancel when the request does not add up

If the task is unexpected, the developer is uncertain or the requested access has no clear purpose, cancel the authorization. A legitimate integration can be revisited after verification. Closing or canceling a request you have not approved is different from removing a grant that already exists; it will not revoke earlier connections.

Approve only when you can say: I initiated this task, I recognize the app and developer, and every requested permission is necessary for the result I expect. If one part is missing, do not click Allow yet. For an account you use at work or school, the organization's policy is part of that decision too.

If you already clicked Allow, go to the recovery section below rather than trying to repeat the setup safely. A later request to authorize the same app can restore the access you just removed. Verify the integration first; do not let a second invitation become an automatic repair step.

The Page Can Be Authentic While the Request Is Not

When you use a "Continue with" button, at least three parties may be involved:

• You, the account holder.

• The identity provider, such as Google or Microsoft.

• The outside app asking the provider for information or account access.

The identity provider authenticates you. It does not necessarily operate, sponsor, or recommend the outside app. An attacker can create or compromise an app, prepare an authorization request, and send that request through email, chat, a QR code, a shared document invitation, or a search result. Google or Microsoft may correctly display their own sign-in and consent pages while the outside app has a malicious purpose.

That is why a domain check answers only one question. It can help you determine whether you are on the provider's site, but it does not tell you whether an outside app deserves permission to read your mail, inspect your cloud files, or act on your behalf.

Think of the provider as a building receptionist checking your ID. The receptionist can confirm that you are you. That does not mean every person waiting in the lobby has a legitimate reason to receive your records.

Apple's explanation of Sign in with Apple describes a narrower identity-sharing flow. When you first use Sign in with Apple, the participating app or website can ask only for your name and email address to set up an account. A genuine Apple page still does not certify the outside app, but it should not be described as a broad Apple-service permission screen.

This does not make all connected apps suspicious. Account integrations and proportionate permissions support useful features such as adding an appointment to a calendar, importing a document, or signing in without creating another password. The safer approach is to separate familiarity from authorization. Apply the same basic habits you would use for any unexpected account request, including the checks in Cybersecurity Basics, even when the first page looks polished and familiar.

What app permissions can authorize

The word "Allow" can sound temporary or minor. Technically, it may authorize the app to receive a token that represents the permissions you approved. The app can then use that token to request permitted data or actions from the provider. It may not need your password, and it may not need to show the consent screen every time it returns.

The exact power depends on the listed permissions. Google's explanation of third-party access levels separates common requests into useful categories:

• Basic account information may include your name, email address, and profile picture.

• View or copy access may let the app retrieve information from a service.

• Manage access may let it edit, create, or delete information.

• Account-action permissions may allow behavior such as sending messages, changing files, or managing settings, depending on the service and scope.

Context matters. A video-meeting service may reasonably need your basic identity and permission to create a calendar event. A document editor may need access to a file you intentionally select. Those same permissions become harder to justify when requested by a coupon tool, simple calculator, one-time file viewer, or service whose purpose has nothing to do with email, contacts, or storage.

Pay particular attention to wording that permits an app to act on your behalf or maintain access when you are not using it. Offline or ongoing access can be legitimate for a background synchronization service, but it also means closing the browser does not necessarily end the connection. In Microsoft's permission model, for example, Mail.Send can permit sending as the signed-in user, Files.ReadWrite can permit reading and changing files, and offline_access can maintain previously granted access. The labels and effects differ across providers, but the decision principle is the same.

Approval is therefore more than a sign-in convenience. It is a grant of authority. Before you approve permissions, you should be able to explain in plain language what the app will be able to see or do. If the permissions cannot be translated into a necessary feature, pause.

Consent Phishing and OAuth Redirect Abuse Are Different Traps

Not every dangerous OAuth link works in the same way. The distinction matters because it changes what you should do afterward.

In a consent-phishing attack, the app asks for permissions. The victim approves them, and the app receives authorized access within those scopes. The attacker's objective may be to read email, inspect files, gather contacts, establish persistence, or use the account's information in another attack.

A different technique uses trusted authorization infrastructure mainly as a route. In March 2026, Microsoft described OAuth redirection abuse that led victims toward phishing and malware. In the campaign Microsoft analyzed, the attacker did not receive an OAuth access token. Instead, crafted authorization URLs and legitimate identity-provider infrastructure helped move the victim toward a malicious destination. Do not assume that denying a consent request makes a later redirect safe: judge the destination and every action it asks you to take.

Your next step depends on what happened:

• If you approved permissions, you need to find and revoke the app connection.

• If you were redirected and entered a password or code on another page, you need to treat the credentials as potentially exposed.

• If a file downloaded but you never opened or ran it, keep it unopened and follow the download branch of recovery. If you opened software, enabled macros, installed an extension or ran a command, the device may need a different response.

• More than one of these events can happen in the same encounter.

Do not let a legitimate first page lower your guard for every page that follows. Recheck the destination, the task, the permissions, and the requested action whenever the flow changes.

Read permissions before trusting familiar branding

The consent screen is not a speed bump to clear before reaching the tool. It is the point where the provider tells you what the tool is asking to receive.

Start with the app's purpose. Then translate the permissions into ordinary actions. "Read your mail" means the app may be able to retrieve message content. "Manage files" may include changing or deleting them. "Send as you" may let the app create messages that appear to come from your account. Exact labels vary across providers, so read the provider's full explanation instead of relying on a short summary.

Google's guidance on third-party connection risks notes that connected services can involve sensitive data from email, photos, Drive, Calendar, and Contacts. It also warns that an outside service may copy data to its own servers. That matters because removing access later does not reach backward and erase every copy already made.

Use these warning signs as decision points:

• You did not initiate the request.

• The app's name is unfamiliar or very close to the name of a well-known product.

• The developer or publisher is not the organization you expected.

• The requested permissions are broader than the stated function.

• A simple task asks to read all files, manage mail, access contacts, or act on your behalf.

• The app requests ongoing or offline access without a clear need.

• The prompt asks for administrator approval.

• The message that brought you there creates urgency, secrecy, or fear of losing access.

• The explanation is vague about where your data will be stored or how it will be used.

The FTC's consumer guidance on app access recommends questioning permissions that do not fit an app's purpose and reviewing the developer's privacy practices. The same principle works for cloud connections: the right amount of access is the smallest amount needed for the feature you chose.

Publisher labels require judgment too. An unverified-app warning is not conclusive proof that an app is malicious. A small or newly registered developer may not have completed a provider's verification process. Still, the warning removes one layer of reassurance. Unless you independently know the developer and understand the permissions request, stopping is the safer choice.

A verified publisher gives you better evidence about the identity associated with the app. It does not prove that every app permission is necessary, that the software cannot be compromised, or that the developer's data practices meet your needs. Microsoft's overview of user and administrator consent pairs publisher verification with low-risk permissions policies, which illustrates the point: identity and permission risk are separate factors.

Use Privacy & Identity Protection to check what data will be shared, who will receive it, and why.

Work and school permissions need the organization's approval

A personal account can expose private email, contacts, or files. A work or school account can also provide a route into shared documents, internal conversations, customer information, research, or organizational systems.

Do not assume a request is approved because your organization uses Google Workspace or Microsoft 365. Those platforms host many outside integrations. Your organization may restrict user consent, permit only lower-risk requests, or require an administrator workflow.

If you already approved an unfamiliar app, contact IT or security promptly while using the provider’s approved recovery controls. Do not wait until you have completed every personal check before reporting it. Administrators may be able to inspect the consent event, determine which permissions were granted, revoke the app centrally, and look for related activity. MITRE's cloud application integration detection guidance specifically identifies unexpected consent grants and OAuth integrations as activity defenders can monitor.

Prompt reporting matters even if you have not noticed missing data or suspicious email. The absence of a visible symptom does not establish that the app was harmless. Tell IT which account was involved and whether you only approved access, entered a password elsewhere, downloaded something or ran software. Those are different exposures. Follow the team’s instructions about preserving messages, logs and the affected device rather than experimenting with additional repair tools.

For organizations deciding what users may approve, Microsoft's consent model supports limiting user consent to verified publishers and selected low-impact permissions or routing exceptions through an administrator workflow. CISA's high-assurance Entra ID baseline likewise recommends restricting user consent, using an admin-consent workflow, limiting app registration, and forwarding security logs. The federal baseline reflects federal risk and licensing assumptions, so private organizations should adapt the controls rather than treating every setting as universal.

If an integration is determined to be malicious, the response must address both the app and affected users. Microsoft's app-consent incident response playbook recommends investigating the grant, requested scopes, affected users, and later activity while disabling the suspicious application. Administrators may also need to revoke user tokens and sessions. A password reset by itself may not remove every app grant or service-issued session.

MFA protects sign-in; permissions still need a separate decision

MFA protects the authentication step by making a stolen password less useful on its own. Keep it enabled. Its value does not depend on whether it can also judge an app request: sign-in protection and careful authorization address different parts of the encounter.

Consent occurs after authentication. If you successfully complete MFA and then approve malicious permissions, the provider can issue that app a valid token. The attacker did not necessarily defeat MFA. The attacker persuaded an authenticated user to authorize access.

The Microsoft Digital Defense Report 2025 highlights why these attacks can persist beyond the controls users normally think of first. App-consent access can outlast a password reset, so changing a password is not a substitute for reviewing and removing authorized applications. Removing a connection is still the right containment step, but it may not invalidate an already-issued access token immediately.

Use MFA to protect sign-in. Use consent-screen judgment to protect authorization. You need both.

If you already approved permissions, remove access and assess exposure

Do not panic, but do not wait for an obvious problem. Your first actions should match the permissions you granted and anything that happened afterward.

1. Remove the app's permissions at the provider

Open the account provider directly, not through the original message. Review connected apps or third-party access, select the questionable app, and remove its access.

For Google accounts, use Google's current instructions for managing linked apps and third-party connections. Distinguish Sign in with Google, a linked account through which Google can receive data from the outside service, and access to your Google Account. For an app with Google Account access, choose the app, open See details, review the permissions, then choose Remove access and confirm. Record the app's scope if available without delaying containment. Google also provides a way to report a questionable app.

For Sign in with Apple, follow Apple's current instructions for managing its connected apps. On iPhone, open Settings, choose your name, then Sign in with Apple, select the app or developer and choose Delete to stop using the connection. This is the narrower identity-sharing flow described earlier. Apple says stopping use signs you out of the app on that device; it does not necessarily delete the separate app account. A developer can group multiple apps, so check which connections the action affects.

Personal Microsoft-account users can open Microsoft's account consent options, review the app and follow the displayed connection-removal controls. Work or school users can use My Apps for permissions they granted personally, but administrator-granted access may require central action. Microsoft's guide to revoking work or school application permissions explains that distinction.

Do not rely only on deleting the outside app from your phone or computer. Uninstalling local software does not necessarily withdraw an authorization stored at the account provider. Removing a Google or Microsoft OAuth connection, stopping a Sign in with Apple connection, withdrawing phone camera or location access, uninstalling an app, and deleting the third-party account are separate actions.

2. Check exposures beyond the app's permissions

Recall the entire path, not just the Allow screen. Did you enter your password only on the provider's real domain? Did the flow send you to a second sign-in page? Did you type a password, one-time code, recovery code or payment information there? Did a file download, and did you open or run it? Did you install an extension, grant remote control or execute a command?

If credentials may have been entered on an untrusted page, change the password through the provider's official site from a device you trust. Review MFA methods, remove unfamiliar recovery options and sign out unknown sessions. Do this alongside removing an app grant if both exposures occurred. A password change and connection removal serve different purposes; completing one does not prove the other is done.

If a file downloaded but you did not open, run or install it, do not open it to see what it contains. For a personal device, remove the unwanted file through the normal file controls and follow your security software's guidance if it raised an alert. For a managed work device, report the download and follow IT's evidence-preservation instructions before deleting it. An unopened download is not the same event as intentionally running a program, although you should report any suspicious behavior or security warning rather than assuming the device is clean.

If you opened an unexpected attachment, enabled macros, installed software or an extension, ran a command or allowed remote access, include that in the device response. Use another trusted device for sensitive account recovery if you suspect the affected one is compromised. On a work or school device, contact IT immediately and follow its containment instructions. Do not try a succession of downloaded “cleanup” utilities supplied by the same page or sender.

Use What To Do If You Clicked a Scam Link to respond based on whether the incident was a simple click, credential exposure, a download or an account change. Keep a short timeline of the actions you actually took. That gives you and any support team a clearer basis for deciding what needs recovery, without treating every encounter as proof of every kind of compromise.

3. Let the granted permissions guide the account review

Use the permissions list to guide the inspection. Do not audit unrelated parts of the account without a reason.

If the app could access email, check:

• Recently sent and deleted messages

• Forwarding addresses

• Inbox rules and filters

• Delegated mailbox access

• Unfamiliar drafts or replies

• Security alerts that may have been archived or deleted

If it could access files, check:

• Recent activity

• New or changed sharing settings

• Public links

• Deleted or moved files

• Sensitive files the app may have been able to read

If it could access contacts or calendars, look for unfamiliar events, changed invitations or messages sent to people in your network. Check any available activity records for evidence of exports, but do not assume that an ordinary account page will reveal every copy the app made. Distinguish what the grant allowed from what the logs show happened. Both facts may matter if sensitive material was within reach.

Google's compromised-account recovery guidance also directs users to review recent security events, devices, two-step verification settings, third-party access, and Gmail rules. Those checks are valuable when the incident may involve more than a single authorization.

4. Alert the Right People

For a work or school account, contact the security or IT team immediately. Provide:

• The app name

• The displayed developer or publisher

• The permissions requested

• The time you approved it

• The message or page that led you there

• Any later redirect, download, or credential entry

• A screenshot, if you can preserve one safely

Do not send passwords, one-time codes or recovery codes. Describe what happened without copying secrets into a report. Share the initiating message or screenshot through the organization’s approved reporting channel rather than forwarding an active authorization link to more colleagues. Include whether the app is still connected and which removal or password-recovery steps you already completed.

If the request appeared to come from a colleague, tell them through another channel. Their account or identity may have been used to reach additional people.

5. Removing permissions does not undo copied data or every session

Removing the connection is a necessary containment action, but it is not a promise that every kind of access ends at the same instant. Microsoft's consent-phishing guidance describes what happens when Microsoft disables a malicious OAuth app: new access-token and refresh-token requests are denied, while existing access tokens remain valid until expiration. That specific behavior should not be treated as a universal timing rule for every provider's Remove access button.

Microsoft's guidance on revoking user access distinguishes Entra-issued authorization from a session issued by the outside app itself. Entra cannot directly revoke that app's own session token; the app controls that session. Follow the provider's recovery instructions and the app's session controls, or ask IT to terminate sessions for an organizational account. Some supported Microsoft services can respond more quickly through Continuous Access Evaluation, but do not assume that all connections support the same mechanism.

Revocation also does not reach backward and erase data already copied. Describe the scope the app held, any evidence of activity and the remaining uncertainty separately. Avoid declaring recovery complete solely because the connection disappeared from a settings page.

If sensitive information may have been copied, review the app's privacy policy and contact the developer to request deletion. For an organizational account, let your legal, privacy, or security team handle that contact when appropriate.

A malicious flow may send another invitation after revocation. Do not assume the second request is a repair step. Reconnect only after you independently confirm the service, developer, permissions and intended task. For a work account, that also means the organization has approved the connection through its normal process. An app appearing in your connection list again is a new fact to investigate, rather than a reason to repeat the authorization.

Conclusion

A correct provider address is reassuring, but it answers only whether you reached that provider. It does not prove that the outside app is trustworthy or needs the access it requests. Keep the task, app, developer and permissions separate in your decision.

Before you click Allow, use Start, Name, Scope, Match, and Exit. If a request is unexpected, overly broad or difficult to explain, cancel it and verify through a separate route. Useful integrations should be able to explain who operates them, what they need and how you can remove the connection later.

If you already approved a questionable Google or Microsoft connection, remove it at the account provider first. If you used Sign in with Apple, stop using that connection through Apple’s current controls. Then let the actual data scope guide your review of mail, files, contacts, calendars, sessions, and security settings. For Microsoft, an existing access token or outside app session can need additional containment; involve IT for a work or school account. Match any credential or device response to what actually happened, and do not treat a password change as a substitute for removing the app.

Get updates on recognizing online risks and recovering when something goes wrong by subscribing to Quantum Cyber AI updates.

FAQ

Is a Google or Microsoft sign-in page safe if the domain is correct?

The correct domain is important because it helps confirm that you are authenticating with the real provider. It does not validate the outside app, the message that sent you there, or the permissions being requested. Treat authentication and authorization as separate checks. Confirm the provider domain, then separately inspect the app name, developer, purpose, and access.

Does MFA stop consent phishing?

Not by itself. MFA helps stop someone from signing in with a stolen password. In consent phishing, you may complete MFA normally and then authorize the malicious app. Keep MFA enabled because it remains valuable against credential attacks, but read every consent request before approving it.

Will changing my password remove app permissions?

Do not assume it will. A connected app may hold a token authorized separately from your current password. Review and remove the app through the provider's connected-app or third-party-access settings. Change the password as well if you entered it on a questionable page or see signs of broader compromise.

Is every unverified app malicious?

No. A legitimate developer may not have completed a provider's verification process. The warning still means you have less assurance about the publisher. Proceed only if you independently know the developer, expected the request, and understand why every permission is necessary.

Is every verified publisher safe?

No. Verification can help link an app to an identified publisher. It does not certify that the app is secure, that it has not been compromised, or that every requested app permission is proportionate. Use it as one signal alongside the task, developer, permissions, privacy practices, and independent documentation.

What does "access your data when you are not using the app" mean?

It generally means the connection can maintain previously granted access without requiring you to be actively signed in to that app each time. This can be necessary for background syncing, alerts, or scheduled tasks. It also makes careful review more important because closing the tab does not necessarily end access.

Which app permissions deserve the most caution?

Scrutinize permissions that allow an app to read or manage email, access broad cloud-storage collections, retrieve contacts, act on your behalf, delete data, or retain ongoing access. The deciding factor is not only how powerful a permission is, but whether it is proportionate to the task.

What should I send my IT team if I already approved an app?

Send the app name, developer, requested permissions, approval time, initiating message, and any later redirects or downloads. Include a screenshot if available. Explain whether you entered credentials anywhere other than the organization's normal provider page. Never send your password or one-time authentication codes.