What we ask for, and what we do with it

You are about to give a vendor read access to every OAuth grant in your company. This page answers that in the order a reviewer asks it.

SCOPES

Permissions we request

The minimum that returns a complete inventory. Every write scope is consented separately, the first time you revoke.

Google Workspace3 SCOPES
READadmin.directory.user.readonly
READadmin.directory.token.readonly
WRITEadmin.directory.token

The write scope is requested on its own screen, the first time you revoke. Declining it leaves the inventory intact.

Microsoft 3653 SCOPES
READApplication.Read.All
READDirectory.Read.All
WRITEApplication.ReadWrite.All

Requires a tenant administrator to consent. The write scope follows the same separate step as Google.

GitHub2 SCOPES
READread:org
READread:user

Installed as an organisation-owned app. Revocation goes through the organisation admin endpoint, not a scope.

Slack1 SCOPE
READadmin.apps:read

Slack exposes no per-user token revocation. Grants are reported here and removed at workspace level.

OktaPLANNED

Scopes published when the connector ships. Every new provider follows the same rule: read-only to inventory, a separate consent to revoke.

AtlassianPLANNED

On the roadmap. Ask us to prioritise a provider, since the order follows what customers actually have connected.

TOKEN HANDLING

What happens to the credentials

Encrypted at rest

Refresh tokens live in a separate keyspace with envelope encryption. Keys rotate every 90 days in a managed HSM.

Never displayed

The interface shows a token prefix and nothing more. No screen, export or log line contains a full token.

Deleted on disconnect

Disconnecting a provider deletes its tokens within one minute and purges the inventory on your retention schedule.

ATTESTATIONS

Where we stand today

AttestationStatusLast assessed
SOC 2 Type IIReport available under NDA2026-02
ISO 27001Certification in progress
Penetration testSummary available under NDA2026-03
GDPRDPA and sub-processor list published2026-04

THIRD PARTIES

Sub-processors

Required reading for a data protection review. Changes are notified 30 days before they take effect.

Sub-processorPurposeJurisdictionDPA
Hetzner CloudCompute and storageGermany and FinlandSigned
StripePayment processingUnited StatesSigned
ResendTransactional emailUnited StatesSigned
GlitchTipError reporting, self-hostedSame region as computeNot applicable

COMMITMENTS

What we owe you when something goes wrong

How fast do you disclose an incident?

Within 24 hours of confirmation, to every affected organisation, by email to the security contact on the account and on the status page. The notice states what was reached, what was not, and what we changed.

Can we report a vulnerability?

Coordinated disclosure with a 90-day window, no legal action against good-faith research, and a named acknowledgement if you want one. Reports go to [email protected].

What is the recovery objective?

Four hours to restore service, one hour of maximum data loss. Scanning resumes automatically; nothing queued for revocation is lost.

Who inside OAuthRadar can see our inventory?

Nobody by default. Support access requires a named ticket, your approval, and it expires in four hours. Every access is in the audit log you can export.

Send this to your reviewer

The SOC 2 report, the penetration-test summary and the sub-processor list, under NDA, on the day you ask.