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).
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.
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.
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.
Het tabblad "Doelgroep" in het Google Auth Platform (voorheen "OAuth-toestemmingsscherm") - hier kiest u het type gebru.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.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.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
Zodra je het OAuth-toestemmingsscherm hebt geconfigureerd, bevindt je externe app zich in Teststatus. Alleen de gebruikers die.
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.
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.
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 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.
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.
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.
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.