Google OAuth-verduidelijkingsscherm: Instellen, Oplossingen & Waarom het niet wordt weergegeven (2026)

Google OAuth-handleiding

Google OAuth-scherm Installatie, Oplossingen En waarom het niet wordt weergegeven (2026)

Het Google OAuth-scherm voor toestemming is in 2024 verplaatst. Het staat nu onder Google Authenticatieplatform in de Cloud Console - niet meer waar je het vroeger vond. Deze handleiding laat je precies zien waar je moet zijn, hoe je het stap voor stap configureert en hoe je de meest voorkomende problemen oplost (inclusief wanneer het weigert te verschijnen).

Wat deze handleiding behandelt
01
Waar te vinden in 2026 - het Google Auth Platform UI dat het oude menu heeft vervangen
02
Niet weergegeven: 5 veelvoorkomende oorzaken en hun precieze oplossingen
03
Volledige stap-voor-stap installatie - Branding, Doelgroep, Scope, Testgebruikers
04
Intern vs Extern - welk gebruikerstype te kiezen en wanneer
05
Sla het toestemmingsscherm volledig overSneller met Unipile's vooraf geverifieerde OAuth-sleutel
2024 UI-wijziging: Google heeft de "OAuth-verificatiescherm" hernoemd naar "Google Auth Platform", met secties genaamd Branding, Doelgroep en Clients. Als je het oude menu niet kunt vinden, is dat de reden.
Te lang; niet gelezen - Snel antwoord

Waar is het? Sinds 2024 bevindt het Google OAuth-toestemmingsscherm zich onder API's en Services > Google Auth Platform in de Cloud Console - niet het oude menu-item "OAuth-instellingenscherm". De instellingen zijn nu opgesplitst in drie tabbladen: Merkidentiteit (app naam, logo, domeinen), Publiek (Intern/Extern gebruikerstype, testgebruikers), en Klanten (OAuth-client-id's). Als het menu helemaal niet verschijnt, heeft uw project nog geen OAuth-compatibele API's ingeschakeld, of uw account heeft niet de rol Eigenaar of Bewerker.

UI-wijziging 2024

Waar is het OAuth-toestemmingsscherm in 2026?

Als je een tutorial volgde die van vóór 2024 dateert en je "OAuth-instelscherm" niet in de linkerzijbalk kunt vinden, dan beeld je het je niet in. Google heeft de hele sectie een nieuwe naam gegeven en geherstructureerd. Het leeft nu onder een nieuwe naam: Google Authenticatieplatform. Dit is de meest voorkomende reden dat ontwikkelaars melden dat het Google OAuth-toestemmingsscherm "niet.

Hoe navigeer ik naar het toestemmingsscherm in 2026

Stap 1: Ga naar console.cloud.google.com en zorg ervoor dat u het juiste project hebt geselecteerd in de projectkiezer bovenaan. Veel "niet tonen"-problemen worden simpelweg veroorzaakt doordat u zich in het verkeerde project bevindt.

Stap 2: Klik in de linkerrandbalk API's en Services.

Stap 3: Zoeken naar Google Authenticatieplatform in het sub-menu (voorheen "OAuth-toestemmingsscherm" genoemd). Als je het ziet, klik erop. Als je het niet ziet, raadpleeg dan het onderstaande gedeelte met probleemoplossingen.

Stap 4: Je komt op het dashboard van het Google Auth Platform. De drie tabbladen - Merkidentiteit, Publieken Klanten - vervang het.

Oude UI (pre-2024)
OAuth-verklaring"
Enkele uitgebreide formulier met alle instellingen
Gebruikerstype bovenaan het formulier
Scopes inline in hetzelfde formulier
Test gebruikerssect
Nieuwe UI - Google Auth Platform (2024+)
Google Auth Platform"
Branding / Doelgroep / Klanten
Gebruikerstype onder tabblad Publiek
Scopes geconfigureerd per OAuth-client onder het tabblad Clients
Testgebruikers ook onder het tabblad Publiek
Google Authenticatieplatform - Tabblad Publiek met selectie van interne vs. externe gebruikerstypen Het tabblad "Doelgroep" in het Google Auth Platform (voorheen "OAuth-toestemmingsscherm") - hier kiest u het type gebru.
Probleemoplossing

OAuth-scherm geeft geen toestemming of blijft doorverwijzen: hoe dit op te lossen

Het Google OAuth-toestemmingsscherm kan om verschillende redenen niet verschijnen of zich onverwacht gedragen. Hieronder vindt u elk foutpatroon met de exacte oorzaak en de oplossing - opgemaakt om zo snel mogelijk te scannen.

Symptoom
Menupunt "OAuth-verificatitescherm" of "Google Auth Platform" ontbreekt in de zijbalk
Oorzaak

De Google Cloud Console UI is in 2024 gewijzigd. Het oude menu-item "OAuth-toestemmingsscherm" is hernoemd naar "Google Authenticatie Platform". Oudere tutorials verwijzen nog steeds naar de oude naam.

Repareer

In de linker zijbalk onder API's en Services, scrollen totdat je ziet "Google Authenticatie Platform". Als u het nog steeds niet ziet, moet u mogelijk eerst ten minste één Google API inschakelen in uw project (de sectie verschijnt pas zodra een OAuth-compatibele API is ingeschakeld).

Symptoom
Google Auth Platform-
Oorzaak

Uw Google-account is niet voorzien van de Eigenaar of Editor IAM-rol op het project. Accounts met de Viewer-rol kunnen instellingen voor het toestemmingsscherm niet bewerken.

Repareer

Vraag de Projecteigenaar om je de Redacteur rol (of hoger) via IAM & Beheer > IAM. Als u het project zelf hebt gemaakt, controleer dan of u bent ingelogd met het juiste Google-account - de projectkiezer toont soms projecten waart.

Symptoom
Je klikt op "Aan de slag" of "Configureren", maar het toestemmingsscherm laadt nooit / blijft doorverwijzen
Oorzaak

Je hebt geen gebruikerstype (Intern vs Extern) nog. In de nieuwe UI verwacht de knop "Aan de slag" op de overzichtspagina van het Google Auth Platform dat je eerst de stap Publiek voltooit.

Repareer

Klik op de Google Auth Platform overzichtspagina "Aan de slag" indien geprompt, ga dan naar de Publiek tab en kies dan tussen Intern of Extern. Zodra een gebruikerstype is opgeslagen, wordt het volledige Branding-configuratieformulier beschikbaar.

Symptoom
OAuth-stroom geeft weer "Deze app is niet geverifieerd" waarschuwingsscherm in plaats van het verwachte toestemmingsscherm
Oorzaak

Uw app is in Teststatus (of de publicatiestatus is "In testen") en je vraagt gevoelige of beperkte scopes aan. Google toont de interstitial "Ongeverifieerde app" vóór het daadwerkelijke toestemmingsscherm.

Repareer

Voor ontwikkeling: voeg het e-mailadres van de testgebruiker toe aan je test gebruikerslijst (Tabblad Publiek). Voor productie: dien uw app in voor de OAuth-verificatie van Google. Gebruikers die als testgebruikers worden vermeld, zien nog steeds een waarschuwing, maar kunnen doorgaan door op "Geavanceerd > Ga naar [App-naam]" te klikken. De waarschuwing verdwijnt zodra uw app is geverifieerd en gepubliceerd.

Symptoom
Het toestemmingsscherm verschijnt één keer, maar wordt nooit meer getoond voor terugkerende gebruikers
Oorzaak

Dit is verwacht gedrag. Zodra een gebruiker toestemming verleent, onthoudt Google de toestemming en slaat het scherm over bij volgende aanmeldingen. Het toestemmingsscherm verschijnt opnieuw alleen als de gebruiker toegang intrekt of als u nieuwe scopes aanvraagt.

Repareer

Om herhalingen af te dwingen voor testen, voeg toe toestemming naar de parameters van uw autorisatie-URL. Gebruik in productie alleen toestemming bij het eerste autorisatiegesprek (om te ontvangen vernieuwingstoken) - niet bij elke login.

Opmerking: als uw app is geconfigureerd als Intern (Alleen voor werkruimteorganisatie) en u test vanuit een extern Gmail-account, het toestemmingsscherm zal nooit verschijnen - u krijgt een toegang_geweigerd fout in plaats daarvan. Interne apps zijn standaard beperkt tot gebruikers binnen uw Google Workspace-organisatie. Schakel over naar Extern als u gebruikers zonder Workspace wilt ondersteunen.
Wil je deze oplossingen overslaan?

Unipile's vooraf geverifieerde OAuth-sleutel elimineert dergelijke foutscenario's uit uw setup - geen configuratie van het toestemmingsscherm aan uw kant, als onafhankelijke technische tussenpersoon die namens elke geauthenticeerde gebruiker optreedt.

Sla deze correcties over
Stapsgewijze installatie

Hoe stelt u het OAuth-toestemmingsscherm stap voor stap in

Dit gedeelte behandelt de volledige configuratie van het toestemmingsscherm - het deel dat u moet voltooien nadat u een Google Cloud-project hebt gemaakt en een Google API hebt ingeschakeld. Als u die stappen nog niet hebt uitgevoerd, raadpleeg dan de Volledige Google OAuth-gids die eerst projectcreatie en API-activering behandelt.

Voorvereisten: U heeft een Google Cloud- API's en Services > Google Auth Platform om te beginnen.
A
Kies uw gebruikerstype: Intern vs Extern

In de Publiek tab, de eerste beslissing is of uw app gebruikers binnen uw Google Workspace-organisatie dient of een Google-accounthouder in het algemeen:

  • Intern: alleen gebruikers binnen uw Google Workspace-organisatie. Geen verificatie vereist. Ideaal voor interne tools, beheerderspanelen of bedrijfsapps die alleen door uw eigen medewerkers worden gebruikt. Niet beschikbaar als uw project is gekoppeld aan een persoonlijk gmail-account (alleen Workspace-accounts).
  • Extern Elke Google-accounthouder. Apps starten in de "Testmodus" met een limiet van 100 gebruikers. Gevoelige of beperkte scopes vereisen het verificatieproces van Google voordat de app voor alle gebruikers kan worden gepubliceerd.
Google Auth Platform Tab "Audience" - kiezen van internas of externas gebruikers type voor het OAuth-instelscherm Audience tab: kies Intern (alleen Workspace) of Extern (elk Google-account). Deze keuze heeft invloed op uw verificatievereisten.

Tip: Je kunt later van Intern naar Extern wijzigen, maar je kunt niet meer van Extern terug naar Intern wijzigen zodra gebruikers je app hebben geautoriseerd. Kies zorgvuldig.

In de Branding tab, vul de volgende velden in. Dit is wat gebruikers te zien krijgen op het Google OAuth-toestemmingsscherm wanneer ze uw app autoriseren:

  • Appnaam: de naam die prominent bovenaan het toestemmingsscherm wordt weergegeven. Gebruik de naam van uw product, geen technische identificatiecode.
  • E-mail voor klantenservice: weergegeven op het toestemmingsscherm als contactpersoon voor gebruikers die vragen hebben over het toegangsverzoek van uw app. Gebruik een gemonitorde alias of distributielijst, geen persoonlijk e-mailadres.
  • App-logo: een vierkant PNG- of JPG-bestand, minimaal 120x120px. Wordt weergegeven op het toestemmingsscherm en in de lijst met geautoriseerde apps in het Google-account. Optioneel maar sterk aanbevolen voor het vertrouwen van gebruikers.
Google Auth Platform Branding tab - App-informatievelden: naam, logo, ondersteunings-e-mail Branding tab - App-informatie: vul de appnaam, het logo en het ondersteunings-e-mailadres precies in zoals u wilt dat ze aan gebruikers worden getoond op het toestemmingsscherm.

Nog in de Branding tab, de sectie App-domeinen vereist de volgende koppelingen:

  • Applicatie startpagina URL: de openbare startpagina van uw app of product. Moet een actieve, toegankelijke URL zijn (geen inlogpagina).
  • Link naar Privacybeleid: vereist voor alle externe apps die beperkingen aanvragen die verder gaan dan basisaan.
  • Link naar Servicevoorwaarden: optioneel maar aanbevolen voor productie-apps.
Google Auth Platform - App-domeingedeelte: homepage, privacybeleid, voorwaarden-URL's App-domein: voer de actuele URL’s in voor uw startpagina, privacybeleid en gebruiksvoorwaarden. Alle URL’s moeten openbaar toegankelijk zijn voordat u ze ter verificatie indient.

De Geautoriseerde domeinen Naast het "App Domain" bepaalt de onderstaande sectie welke domeinen gebruikt mogen worden in je OAuth redirect URIs en in de app-domeinlinks hierboven. Voeg het hoofddomein van je applicatie toe (bijvoorbeeld. yourapp.com).

Google Auth Platform Branding tab - Geautoriseerde domeinen configuratie Geautoriseerde domeinen: voeg uw hoofddomein toe. Alleen omgeleide URI's en app-URL's van dit domein worden door Google geaccepteerd.

Tip: geautoriseerde dome https://app.yourapp.com/callback, je moet autoriseren yourapp.com hier, niet app.yourapp.com.

Ook in de Branding tab, geef een e-mailadres voor ontwikkelaarscontact op. Dit is het adres dat Google gebruikt om te verzenden:

  • Verificatiestatusupdates (goedkeuring, afwijzing of verduidelijkingsverzoeken)
  • Nalevingsmeldingen beleid
  • Meldingen over wijzigingen in de OAuth-status van uw app
Google Auth Platform - Contactgegevens voor ontwikkelaarsvelden Ontwikkelaarscontact: gebruik een bewaakte distributielijst. Kritieke Google-verificatiemails kunnen als spam worden gefilterd - controleer de spammap tijdens uw beoordelingsperiode.

Belangrijk: gebruik een distributielijst of gedeelde inbox, geen persoonlijke e-mail. Het verificatieteam van Google kan e-mails sturen tijdens kantooruren in een andere tijdzone. Als je het antwoordvenster mist, kan je verificatie met weken worden vertraagd.

Scopes bepalen welke gegevens uw app namens de gebruiker kan openen. In de nieuwe Google Auth Platform-interface kunnen scopes per OAuth-client worden geconfigureerd (onder de Klanten-tabblad selecteer een client > Scopes). Klik op "Scopes toevoegen of verwijderen" om de scopekiezer te openen.

Reikwijdte-categorieën die uw verificatiepad beïnvloeden:

  • Niet-gevoelige bereiken (bijvoorbeeld. openid, e-mail, profiel): Basis aanmelding, geen verificatie vereist. App wordt direct gepubliceerd.
  • Gevoelige bereiken (bijvoorbeeld. gmail.alleenlezen, gmail.verzenden, gmail.labels): vereist een Google beveiligingsbeoordeling (OAuth-verificatie). App blijft in de testmodus totdat deze is geverifieerd.
  • Beperkte bereiken (bijvoorbeeld. mail.google.com, gmail-aanpassen): vereist én Google OAuth-verificatie én een CASA Tier 2-beveiligingsaudit. Kost aanzienlijk meer tijd.
Google Auth Platform - Scopes toevoegen of verwijderen paneel met beschikbare Gmail API-machtigingen Scopekiezer: kies de minimale benodigde scopes voor uw app. Elke gevoelige of beperkte scope voegt verificatievereisten toe. Plan dit voordat u begint met bouwen.

Voor een volledige referentie van Gmail-specifieke bereiken, welke API's elk bereik ontgrendelt en hoe u deze in uw autorisatielink aanvraagt, raadpleegt u de Gmail API Scopes Gids.

Principe van minimale privileges vraag alleen scopen aan die je app momenteel gebruikt. Het toevoegen van een beperkte scope na de lancering betekent het opnieuw doorlopen van het volledige verificatieproces, inclusief een nieuwe CASA Tier 2-audit.

In de Publiek tab, de Testgebruikers sectie kun je Google-account-e-mails toevoegen die je app kunnen autoriseren terwijl deze zich in de Teststatus.

Belangrijke regels over de limiet van testgebruikers:

  • Maximaal 100 testgebruikers kan worden toegevoegd aan een externe app in de status Testen. Dit is een harde limiet van Google - u kunt deze niet verhogen zonder uw app te publiceren.
  • Testgebruikers zien het waarschuwingsscherm "ongeverifieerde app", maar kunnen uw app nog steeds autoriseren door op de waarschuwing te klikken.
  • Toegangstokens voor testgeb 7 dagen. Gebruikers moeten opnieuw autoriseren wanneer de token verloopt.
  • Zodra u voor verificatie indient en Google uw app goedkeurt, wordt de limiet van 100 gebruikers opgeheven en de 7-daagse vervaldatum verdwijnt.

Als je meer dan 100 gebruikers nodig hebt voor verificatie: de enige optie is om je app in te dienen voor Google-verificatie. Er is geen oplossing binnen de systemen van Google. Overweeg als alternatief of de vooraf geverifieerde OAuth-sleutel van Unipile (volgende sectie) de OAuth-stroom voor je kan afhandelen, waardoor zowel.

Wil je dit hele proces van de OAuth-toestemmingsschermconfiguratie overslaan?

Gebruik Unipile's geverifieerde OAuth-sleutel in plaats daarvan – geen instelling van een toestemmingsscherm, geen limiet van 100 gebruikers, geen wacht.

Gebruik de sleutel van Unipile
Gebruikerstypebeslissing

Intern vs Extern: welke moet je kiezen?

De keuze tussen Intern en Extern op het Google OAuth-verlichtingsscherm is een van de meest ingrijpende beslissingen in uw configuratie. Het bepaalt uw verificatiepad, uw gebruikersbestand, en of u tijdens de ontwikkeling te maken krijgt met een limiet van 100 gebruikers. Hier is het volledige plaatje.

Intern
Werkruimteorganisatie alleen
Geen verificatie vereist - ooit
Geen testgebruikerlimiet
Geen waarschuwingsscherm "ongeldige app"
Vereist een Google Workspace-account (geen persoonlijke Gmail)
Kan geen externe klanten bedienen
Geschikt voor: interne bedrijfsapplicaties, beheerdersdashboards, ontwikkelaarstools, HR-apps, elke app waarbij alle gebruikers zich in uw Workspace-organisatie bevinden.
Extern
Elk Google-account
Elke Google-account kan je app autoriseren
Werkt met persoonlijke Gmail- en Workspace-accounts
100-gebruiker limiet in Testmodus
Gevoelige/beperkte bereiken vereisen Google-verificatie
Gebruikers zien een "ongeverifieerde app" waarschuwing totdat deze is geverifieerd
Geschikt voor: SaaS-producten, consumentenapps, ontwikkelaarstools die elke klant met een Google-account bedienen.
Snelle beslissingsgids
Zullen er gebruikers buiten uw Google Workspace-organisatie zijn?
Ja - kies Extern
Is uw project gekoppeld aan een persoonlijk Gmail-account (geen Workspace)?
Moet extern worden gebruikt
Een interne tool bouwen waarbij alle gebruikers zich in de Workspace-organisatie van uw bedrijf bevinden?
Intern gebruik
Wil je de verificatie door Google helemaal vermijden en toch externe gebruikers bedienen?
Zie het gedeelte 'Overslaan' hieronder

Sla de interne versus externe beslissing volledig over

Met Unipile's vooraf geverifieerde OAuth-sleutel bedient u externe gebruikers zonder Google-verificatie - Unipile functioneert namens elke geauthenticeerde gebruiker als een onafhankelijke technische tussenpersoon.

Sla de installatie over
Na de installatie

Na het toestemmingsscherm: verificatie en CASA

Het voltooien van de configuratie van het Google OAuth-toestemmingsscherm is niet het einde van het proces voor externe apps die gevoelige of beperkte scopes aanvragen. Wat er daarna volgt, hangt af van de scopes die je hebt gekozen. Hier volgt een korte samenvatting – de volledige uitleg over de verificatie en CASA vind je in de Google OAuth hub.

1
App is in testmodus (100 gebruikerslimiet)

Zodra je het OAuth-toestemmingsscherm hebt geconfigureerd, bevindt je externe app zich in Teststatus. Alleen de gebruikers die.

2
Indienen voor Google OAuth-verificatie

Als je klaar bent om je app voor meer gebruikers beschikbaar te maken, klik je op ""Maak je klaar voor de verificatie"" (of 'Ter verificatie indienen') in het overzicht van het Google Auth Platform. Google controleert het privacybeleid van je app, de geautoriseerde domeinen, de aangevraagde scopes en de manier waarop je app de gegevens gebruikt. De beoordelingstermijn varieert – doorgaans 2 tot 6 weken, soms langer bij beperkte scopes.

3
CASA Tier 2-audit (alleen beperkte reikwijdte)

Als je app beperkte scopes aanvraagt (zoals mail.google.com of gmail-aanpassen), vereist Google bovendien een CASA Tier 2-beveiligingsaudit door een erkende externe beoordelaar. Hierbij worden de beveiligingsstatus, de gegevensverwerking en de toegangscontroles van uw app onder de loep genomen.

4
App gepubliceerd - geen waarschuwingen meer

Zodra je app is geverifieerd, wordt deze gepubliceerd. Het waarschuwingsscherm met de melding 'niet-geverifieerde app' verdwijnt. De limiet van 100 gebruikers wordt opgeheven. De geldigheidsduur van 7 dagen voor tokens van testgebruikers vervalt. Gebruikers zien je toestemmingsscherm met je eigen huisstijl, zonder waarschuwingen.

Voor een breder overzicht van hoe Google OAuth in de e-mail-API-architectuur past – inclusief uniforme toegang tot providers via Gmail, Outlook en IMAP – zie de E-mail API-handleiding.

Unipile is CASA Tier 2-gecertificeerd

Unipile heeft de CASA Tier 2-audit voor zijn Google OAuth-integratie al afgerond. Dit betekent dat wanneer u Unipile gebruikt als een onafhankelijke technische tussenpersoon, actief namens elke geauthenticeerde gebruiker, hoef je het CASA-proces niet zelf te doorlopen. Zie de Volledige Google OAuth-hub voor de details over het certificeringspad van Unipile en hoe de POC / later certificeren / wisselen workflow werkt.

Sneller Pad

Sla de instelling van het toestemmingsscherm helemaal over

Als uw product toegang moet krijgen tot Gmail- of Google Agenda-gegevens van gebruikers, kunt u ervoor kiezen om de Google OAuth-toestemmingsschermconfiguratie zelf af te handelen - of u kunt Unipile als onafhankelijke technische tussenpersoon, actief namens elke geauthenticeerde gebruiker, met een vooraf geverifieerde OAuth-sleutel die al CASA Tier 2-certificering heeft. Dit is geen oplossing voor de beveiligingscontrole van Google. Unipile heeft die beoordeling voor u afgerond - dat is het product.

Unipile is niet gelieerd aan, goedgekeurd door, of gesponsord door Google. Unipile opereert als een onafhankelijke technische tussenpersoon tussen uw applicatie en de Google OAuth-infrastructuur.

Configureer het zelf
Configureer uw eigen OAuth-instelscherm
Configureer de tabbladen Branding, Publiek en Klanten in het Google Authenticatieplatform
100-gebruikerslimiet tijdens testfase
Google OAuth-verificatie (2-6 weken)
CASA Tier 2 audit (voor beperkte reikwijdte)
Gebruikers zien een "ongeverifieerde app" waarschuwing totdat deze is geverifieerd
Gebruik de sleutel van Unipile
De vooraf geverifieerde OAuth-integratie van Unipile
Configuratie van het scherm voor toestemming op uw kant
Geen 100-gebruikerslimiet - direct naar al uw gebruikers sturen
Google-verificatie al gedaan
CASA Tier 2-certificering reeds voltooid
Geen waarschuwing over "niet-geverifieerde apps" voor uw gebruikers
Begin met bouwen. Er is geen toestemmingsscherm nodig.

Koppel de Google-accounts van uw gebruikers via de geverifieerde OAuth-integratie van Unipile. Uw gebruikers geven één keer toestemming – Unipile regelt de rest, als onafhankelijke technische tussenpersoon, namens elke geauthenticeerde gebruiker.

Dit is geen tijdelijke oplossing om de beveiligingscontrole van Google te omzeilen. Unipile heeft de OAuth-verificatie van Google en de CASA Tier 2-audit doorlopen als onderdeel van zijn productaanbod. Uw applicatie maakt via Unipile verbinding met de API’s van Google, waarbij Unipile optreedt als een geverifieerde, onafhankelijke technische tussenpersoon. Unipile is niet gelieerd aan, wordt niet aanbevolen door en wordt niet gesponsord door Google. Beslissingen aan de kant van de klant met betrekking tot gegevensgebruik en toestemming van gebruikers blijven de verantwoordelijkheid van uw applicatie.

Google OAuth-verificatiescherm - Veelgestelde vragen

De meest gestelde vragen over het configureren, oplossen van problemen en navigeren door het Google OAuth-toestemmingsscherm in 2026.

Er zijn vijf veelvoorkomende redenen: (1) Je zoekt naar het oude menu "OAuth-toestemmingsscherm" - het is hernoemd naar "Google Authenticatie Platform" in 2024. (2) Je bent in het verkeerde project terechtgekomen – kijk even naar de projectkiezer bovenaan. (3) Uw account beschikt niet over de IAM-rol 'Eigenaar' of 'Redacteur'. (4) Er is nog geen OAuth-compatibele API ingeschakeld voor het project – het gedeelte 'Google Auth Platform' wordt pas weergegeven zodra er een API is geactiveerd. (5) Uw app is geconfigureerd als Intern, maar u test met een externe Google-account. Interne apps blokkeren opzettelijk alle externe Workspace-gebruikers. Zie de voor gedetailleerde oplossingen Probleemoplossingssectie hierboven.

Ga vanaf 2024 naar API's en Services > Google Auth Platform. Het oude menu-item "OAuth-toestemmingsscherm" bestaat niet meer – het is vervangen door Google Auth Platform, dat de instellingen in drie tabbladen indeelt: Merkidentiteit (app naam, logo, domeinen), Publiek (Intern/Extern gebruikerstype, testgebruikers), en Klanten (OAuth-client-ID's en omleidings-URI's). Deze herstructurering van de gebruikersinterface is de belangrijkste oorzaak van de zoekopdracht "het Google OAuth-toestemmingsscherm wordt niet weergegeven" in 2026.

Meer hierover in onze Volledige Google OAuth Playground handleiding.

Intern: alle gebruikers maken deel uit van uw Google Workspace-organisatie, er is nooit verificatie nodig, er geldt geen limiet voor het aantal testgebruikers en er verschijnt geen waarschuwing voor niet-geverifieerde gebruikers. Ideaal voor interne tools. Hiervoor is een Workspace-account vereist (geen persoonlijk Gmail-account).

Extern: elke Google-accounthouder kan je app gebruiken. De app start in de testmodus (maximaal 100 gebruikers). Voor gevoelige scopes is verificatie door Google vereist (2-6 weken). Voor beperkte scopes is bovendien CASA Tier 2 vereist. Kies ‘Extern’ voor elke openbare of klantgerichte applicatie.

De harde limiet is 100 testgebruikers voor externe apps met de status ‘In testfase’. Deze limiet is door Google ingesteld en kan niet worden omzeild. Testgebruikers kunnen je app nog steeds autoriseren, maar krijgen eerst een waarschuwingsscherm te zien. Hun tokens verlopen na 7 dagen (in plaats van de gebruikelijke geldigheidsduur van het vernieuwingstoken). Om deze limiet op te heffen, dient u uw app in voor OAuth-verificatie door Google. Zodra de app is gepubliceerd, geldt er geen limiet meer voor het aantal gebruikers.

Dat hangt af van je instellingen: Interne apps hoeven nooit te worden geverifieerd. Externe apps die alleen basisbereiken gebruiken (openid, e-mail, profiel) kunnen publiceren zonder verificatie. Externe apps die gevoelige bereiken aanvragen zoals gmail.verzenden, gmail.alleenlezen) moet de OAuth-verificatie van Google doorstaan voordat de limiet van 100 gebruikers kan worden opgeheven. Externe apps die beperkte scopes aanvragen zoals mail.google.com) vereisen daarnaast een CASA Tier 2 beveiligingsaudit - bovenop de standaard verificatie. Zie de Gmail API Scopes Gids voor de volledige reikwijdte classificeering.

Je kunt het Google OAuth-toestemmingsscherm binnen Google's eigen infrastructuur niet overslaan - het is een vereiste stap voor elke OAuth 2.0-stroom. Je kunt echter het zelf configureren en laten verifiëren vermijden door gebruik te maken van Unipile's vooraf geverifieerde OAuth-sleutel. Unipile fungeert als een onafhankelijke technische tussenpersoon, namens elke geauthenticeerde gebruiker, met Google-verificatie en CASA Tier 2-certificering reeds voltooid. Dit is geen beveiligingsoplossing - Unipile heeft het volledige beoordelingsproces van Google doorlopen. Uw gebruikers zien nog steeds een toestemmingsscherm (het geverifieerde scherm van Unipile), u hoeft er alleen geen eigen scherm te bouwen en te verifiëren.

Ontdek productierijpe Gmail API-integratie.

Nog vragen over de Google OAuth-instellingen? Ons team staat voor u klaar om te helpen.

Praat met een expert
nl_NLNL