Signing In Asks for Less
One Google app sits behind signing in, calendar sync, sending mail and the document archive, and each asks for something different at a different moment. Sign-in asks for the least of all, and the connector that asks for the most is built to cope with a person who only agrees to half of it.
Ask a security reviewer what worries them about "Sign in with Google" and the answer is rarely the sign-in. It is what else the button might have quietly agreed to. A single consent screen that bundles who you are with read and send your email is how an identity integration becomes a data integration without anybody choosing that. The fix is not a cleverer consent screen. It is asking for each thing at the moment it is needed, by the person who needs it.
One Google app, four doors
Behind the scenes there is a single registered Google application. Four features use it, and they ask for very different things:
- Signing in asks for identity only: that you are a Google account holder, your name, your address and whether Google has verified it.
- Google Workspace asks to manage calendar events and to send email from the connected account — the two permissions Google classes as sensitive.
- Google Drive asks for access to the files this app itself creates in your Drive, and nothing else in it.
- Google Sheets asks for the same per-file access, for the spreadsheets it builds.
The three connectors are switched on from the connector settings by somebody administering the workspace. Signing in is something every user does. Keeping those two apart is the whole design.
What signing in does not ask for
The sign-in request carries the three standard identity permissions and nothing more. It does not ask for offline access, which matters as much as the permission list: without it Google issues no long-lived token, so a sign-in leaves nothing behind that could act on your account later.
Signing in proves who you are. It never grants the product anything it could use while you are not there.
So a user who signs in with Google has not, by doing so, let the product near their calendar or their mail. Those permissions exist only on an account an administrator deliberately connects — usually one shared mailbox for the organisation — and an ordinary user's sign-in never touches them.
What the Workspace connector asks for, exactly
The two sensitive permissions are the narrowest Google offers for the job. The calendar permission covers events, not the calendar's settings or who it is shared with, and the app only ever creates and updates its own deadline events, which it finds again by a private tag it puts on each one. The mail permission is send-only: it cannot read the inbox.
And what they are used for is a closed list. Calendar events are created for three kinds of deadline: expected delivery dates on purchase orders, approval due dates, and RFQ response and quotation expiry dates. Mail can be sent from the connected account for four kinds of document: purchase orders and RFQ invitations to vendors, and invoices and payment receipts to customers. Everything else the product sends still goes through the platform's own mailer.
Gmail sending also starts switched off. Connecting the account grants the permission; choosing which of the four documents actually go out through it is a second, separate decision on the settings page.
When somebody agrees to only half
Google's consent screen lets the person granting access untick individual permissions and still finish. Somebody happy to put delivery dates in the calendar but not to let an application send mail as them can say exactly that.
The naive integration does not notice. It asked for two permissions, the handshake succeeded, so it stores the connection as fully working — and the first time it tries to send an email, weeks later, it fails against Google with a raw permissions error that nobody connects to a checkbox.
-
Read back what was actually granted
Google returns the list of permissions the person agreed to. That list, not the list requested, decides what is switched on.
-
Nothing granted means nothing connected
If neither Calendar nor Gmail came back, the connection is refused with a message saying so, rather than stored as a connection that can do nothing.
-
Half granted means half switched on
The connection is saved, the declined feature is switched off, and the message names what was declined and what still works.
-
A narrower reconnect turns features off
Reconnecting with less than before switches off whatever is no longer granted, even if it was on, instead of keeping the old setting.
The last step is the one most integrations miss, because it only bites on a second connection. Somebody connects with both permissions, Gmail sending is switched on, and later they reconnect — a new mailbox, an expired grant — and untick Gmail. A declined permission switches its feature off, rather than leaving a setting pointing at access that no longer exists.
The refresh token that is only given once
One more Google behaviour shapes the connector. The long-lived token that lets it keep working after the person leaves is normally issued only the first time an account approves the application. Reconnecting an account that has approved it before can come back without one.
The connector asks Google to show the consent screen every time, which is what makes it reissue the token. If one still does not arrive, the connection is refused rather than saved half-working, and the message gives the fix: remove the application from the Google account's permissions and connect again.
What is in place
What each Google door asks for
Sign-in asks for identity only
The Google sign-in requests the three standard identity permissions and no access to mail, calendar or files.
No offline access at sign-in
Signing in requests no long-lived token, so it leaves nothing that could act on the account later.
Connectors switched on deliberately
Calendar, Gmail, Drive and Sheets access is requested only when a workspace administrator connects that integration.
The narrowest sensitive permissions
The calendar permission is for events rather than calendar settings, and the mail permission is send-only, with no inbox access.
Only its own events touched
The app creates and updates its own deadline events and finds them again by a private tag, leaving everything else in the calendar alone.
A closed list of uses
Calendar events for three kinds of deadline and email for four kinds of document; everything else stays on the platform mailer.
Gmail sending off until chosen
Connecting grants the permission; choosing which documents go out through Gmail is a separate setting that starts empty.
The granted list decides
Features are switched on from the permissions Google reports as granted, not from the permissions requested.
Partial consent handled
A grant with one permission declined is saved with that feature off and a message naming what still works.
An empty grant refused
A handshake that granted neither Calendar nor Gmail is refused instead of saved as a connection that can do nothing.
Narrower reconnects switch features off
Reconnecting with fewer permissions turns off what is no longer granted, even where it was previously enabled.
A missing refresh token refused with the fix
The consent screen is requested every time, and a connection without a long-lived token is refused with instructions to remove and reconnect.
Drive and Sheets limited to their own files
The document connectors use per-file access, reaching only the files the app creates or is given.
The first two items are what a security review usually asks about, and the seventh is what keeps the connector honest afterwards: the product acts on what the person actually agreed to, read back from Google, rather than on what it hoped they would.
Three positions held on purpose
- Identity and access are asked for separately. Folding calendar or mail permissions into the sign-in would make every user's login a grant of access to their account; keeping them on a connector an administrator turns on means only the mailbox somebody chose is ever involved.
- The person granting access gets to say no to part of it. A connection with only calendar access is a legitimate, useful connection, and it is saved as one rather than refused or treated as broken.
- A setting cannot outlive its permission. When a reconnect grants less, the features that depended on the missing permission are switched off on the spot, because a setting that points at access that no longer exists fails later and somewhere else.
Five questions to ask about Google access
Does "Sign in with Google" give you access to my email?
A good answer sounds like
No.
What ours actually is
No. Sign-in requests identity only and no long-lived token.
What exactly can the Gmail permission do?
A good answer sounds like
Send, not read.
What ours actually is
Send only, for purchase orders and RFQ invitations to vendors and invoices and receipts to customers, and only the ones you switch on.
And the calendar permission?
A good answer sounds like
Events, not the whole calendar.
What ours actually is
It creates and updates its own deadline events — delivery dates, approval due dates, RFQ and quotation deadlines — and leaves everything else alone.
What if I untick one permission?
A good answer sounds like
It should still work for the other.
What ours actually is
It connects with that feature off and tells you what still works.
What if I reconnect with less than before?
A good answer sounds like
Features should follow.
What ours actually is
Anything no longer granted is switched off at once, even if it was on.
Our take
The useful question about any "Sign in with Google" button is not which permissions the product asks for in total, it is which of them ride along with the login. Here the answer is none: signing in asks who you are and keeps nothing it could use later, and the sensitive permissions sit on a connector somebody turns on for one chosen account. The less visible half matters as much. Google lets a person agree to part of a request, and a connector that trusts what it asked for instead of what it was given stores a working connection that is not one. Reading the grant back, and letting it switch features off as well as on, is what makes partial consent a choice rather than a bug.
Walk through Google access with your security team
Which permissions each feature uses, who grants them and what they are used for is a short, specific conversation.
Talk through Google accessFrequently asked questions
Does signing in with Google let the product read my email or calendar?
No. Signing in requests only your identity — your name, your email address and whether Google has verified it — and no long-lived token. Calendar and Gmail access belong to the Google Workspace connector, which an administrator connects separately for one chosen account.
What does the Google Workspace connector use Gmail for?
Sending only, never reading. It can send purchase orders and RFQ invitations to vendors, and invoices and payment receipts to customers, from the connected account — and only the document types you switch on. Gmail sending starts switched off; everything else still goes through the platform mailer.
What calendar events does it create?
Three kinds: purchase order expected delivery dates, approval due dates, and RFQ response and quotation expiry deadlines. It creates and updates only those events, which it finds again by a private tag, and leaves the rest of the calendar alone.
Can I connect Calendar but not Gmail?
Yes. Untick Gmail on Google's consent screen and the connector is saved with Calendar on and Gmail off, with a message saying so. Reconnect with both ticked if you change your mind.
The connector says Google did not return a refresh token. What do I do?
Remove AWRA OpsHub from your Google account's third-party access permissions, then connect again. Google issues the long-lived token on a fresh approval, and the connector refuses to save a connection without one rather than letting it fail later.
