OAuth is good, but Google and Microsoft turn it into a gate

OAuth is a security improvement

Moving away from Basic Authentication, long-lived passwords and broadly privileged credentials was the right decision. OAuth enables limited permissions, short-lived access tokens, revocable connections and better control over what an application can actually do.

The standard is open. It explains how an application can request and obtain access on a user's behalf. It does not itself require developers to submit business documents, organisational evidence, demonstration videos or an admission application to a platform operator. That additional layer comes from ecosystem rules.

An open standard can still become a closed gate

SMTP and IMAP emerged in an internet built around interoperability. A provider could run a mail server, a developer could build a client and the two could communicate through documented standards.

OAuth does not destroy that openness. But when mailbox access additionally depends on the platform owner's approval, the decisive question shifts: does the user authorise the application, or does Google or Microsoft decide whether that application may be authorised at all?

A security review asks an application to demonstrate secure, purpose-bound handling of user data. Gatekeeping instead repeatedly asks its publisher to justify why the application may exist in the ecosystem. This article argues that the distinction matters, while recognising the sensitivity of mailbox data.

Microsoft 365: consent often stops at the tenant boundary

The Microsoft barrier described here is often not a Google-style video review. It is the interaction between Microsoft Entra ID, publisher verification, administrator consent and each Microsoft 365 tenant's policies.

Microsoft recommends limiting user consent to verified publishers and selected permissions classified as low risk. Administrators can restrict it further or disable it. A user may explicitly want a mailbox integration and still be told that administrator approval is required.

Publisher verification can also be decisive for newer multitenant applications. Among other requirements, the publisher needs a verified Microsoft AI Cloud Partner Program account connected to the app registration. It is an understandable trust signal, but also links the usability of open authorisation to Microsoft's business and partner procedures.

Google and Gmail: scope review can become a product bottleneck

Gmail's process is more centrally controlled. The policy classifications described at publication identify gmail.send as sensitive and gmail.readonly as restricted. Public applications requiring these permissions may need brand and domain evidence, a precise scope justification and a demonstration video, depending on their use.

The video must show the full OAuth flow, the exact consent screen and the features using every requested scope. If the justification is rejected or the presentation does not match the application in the reviewer's assessment, further questions, new recordings or another submission can follow.

The published article cites nonbinding Google estimates of two to three business days for brand verification, ten business days for sensitive scopes and up to six weeks for restricted scopes. Storing or transmitting restricted Gmail data on a server may additionally require an annually repeated security assessment. These are the policy descriptions and estimates associated with the original publication, not a new promise about approval time.

The 100-user limit has practical consequences

In testing mode, access is limited to at most 100 explicitly listed test users, whose authorisations expire after seven days under the conditions described in the linked Google guidance. Unverified applications may also encounter a lifetime cap of 100 new users.

If a sensitive or restricted scope is rejected, users can no longer access that unapproved scope. A cap or denial is therefore not merely an administrative warning: it can stop the product feature that a user is trying to enable.

Why Hassolux needs these permissions

Hassolux is a work platform for construction and service businesses, bringing projects, documents, invoices and communication into a traceable workflow. An authorised user deliberately enables its optional mailbox connection.

For Microsoft 365, delegated Mail.Read and Mail.Send access supports reading incoming messages on behalf of the signed-in user and sending document emails explicitly requested by that user. For Gmail, gmail.readonly retrieves selected messages and PDF/XML attachments, while gmail.send is used separately for user-initiated outgoing mail.

Hassolux searches only the period selected by the user, reads sender, subject and receipt time, and imports supported PDF or XML attachments for invoice processing. It does not move, mark, modify or delete Gmail messages. Sending is separate and occurs only after a specific user action. The connection can be removed and additionally revoked at the provider.

A request for a smaller scope can become technically contradictory here. A metadata-only permission does not provide message content or invoice attachments; the application cannot import a document it is not allowed to read. For this visible feature, gmail.readonly is requested as the narrowest Google permission that provides the necessary access, not as a precautionary collection of broader rights.

Our experience: repeated demonstrations and still a rejection

For Hassolux, Google verification involved more than implementing the integration. We repeatedly produced demonstration videos, waited through review cycles, answered status emails and explained why the scope was necessary. Rejection of that scope removes more than an abstract API permission: it removes the feature for which a user wants to connect their own mailbox.

Sensitive email data justifies demanding security requirements. A review must nevertheless distinguish excessive collection from a technically necessary minimum permission. Otherwise least privilege becomes impossible to satisfy: the platform offers no narrower usable scope but rejects the available scope as too broad. This is the author's account and argument about the review experience, not a claim that all applications receive the same treatment.

What a fair verification process should provide

The proposed improvements are intended to retain protection while making independent integrations feasible.

• Clear criteria that can be checked in advance: developers should know which uses are permitted before implementation.
• Specific, understandable decisions: a rejection should identify the concrete technical or privacy-related mismatch.
• Proportionate evidence: assess data flow, storage location and actual risk rather than mainly the publisher's size.
• Reusable reviews: a small product change should not restart the entire evidentiary process.
• A meaningful technical appeal: account for cases where the provider offers no narrower functioning scope.
• Effective user choice: informed consent and revocation at any time should carry more weight than blanket platform limits.

Open authorisation should remain open

We support OAuth, stronger authentication and consistent protection of user data. That is precisely why criticism of the approval mechanisms built above it must be possible. Security should protect people from harmful applications without casually increasing barriers to entry or strengthening platform owners' control over interoperable software.

A standard can be open on paper. In practice, openness also requires independent developers, start-ups and smaller software businesses to use it under transparent, fair conditions. The internet's future should not depend on a handful of platforms granting permission for every technically necessary integration.