top of page
  • Writer's pictureAdam Claes

Google blokkeert OAuth-verzoeken die via ingesloten browsers zijn gedaan

Google kondigde vorig jaar aan dat het vanaf 20 april 2017 geen OAuth-verzoeken meer accepteert van embedded browsers, ook wel bekend als webviews. Voorheen konden ontwikkelaars OAuth-verzoeken indienen bij Google met behulp van webweergaven zoals het WebView UI-element in Android, UIWebView/WKWebView op iOS en de equivalenten op Windows en OS X.


Google heeft in november 2016 een melding op hun iOS-toestemmingspagina gepubliceerd om ontwikkelaars op de hoogte te stellen van de naderende beëindiging. De identieke melding werd eerder dit jaar, in maart 2017, op de Android-toestemmingspagina geïntroduceerd.


Google heeft OAuth-toestemmingsverzoeken via webweergaven per 20 april 2017 beperkt. Helaas zijn veel ontwikkelaars nog niet afgestapt van het gebruik van ingesloten browsers om dergelijke verzoeken in hun bestaande apps uit te voeren. Als gevolg hiervan ontvangen gebruikers die proberen in te loggen bij apps van derden die nog steeds webweergaven gebruiken voor OAuth-aanmeldingen, vaak de gevreesde 403-niet-toegestane user-agent-fout, zoals hieronder weergegeven:




Oplossing voor gebruikers en ontwikkelaars


Een oplossing is dat ontwikkelaars hun apps upgraden om de Google Sign-in SDK voor Android en iOS te gebruiken, die wordt aanbevolen voor inloggen en OAuth met Google-accounts.


AppAuth (open source OAuth-clientbibliotheek) voor Android, iOS en OSX is een andere keuze.


Met de GTMAppAuth-bibliotheek (iOS en OSX) kunt u AppAuth gebruiken met de Google Toolbox voor Mac - Session Fetcher en Google API's Client Library voor Objective-C For REST-bibliotheken door het GTMFetcherAuthorizationProtocol te implementeren voor het autoriseren van verzoeken met AppAuth.


Ontwikkelaars op Windows kunnen de OAuth voor apps: Windows-voorbeelden bekijken om te leren hoe ze een OAuth-autorisatiestroom naar Google kunnen bouwen in een systeemeigen app met behulp van de apparaatbrowser (in plaats van een ingesloten browser). Hieronder volgen enkele specifieke voorbeelden:


  • OAuthUniversalApp

  • Een voorbeeld van een Universal Windows Platform-toepassing.

  • OAuthDesktopApp

  • WPF-voorbeeld van een traditionele desktop-app (Windows Presentation Foundation).

  • OAuthConsole-app

  • een voorbeeld van een consoletoepassing.

Terzijde: Auth0 gebruiken


Gebruikersauthenticatie en identiteitsbeheer zijn twee van de moeilijkste aspecten om in een applicatie op te nemen. Voor Google Sign-in en OAuth met Google-accounts wordt Auth0 geleverd met de mogelijkheid om apparaatbrowsers te gebruiken (in plaats van ingesloten browsers). Het gebruik van bedrijven zoals Auth0 om deze functie te bouwen, bespaart u als ontwikkelaar veel tijd en moeite. U hoeft zich geen zorgen te maken over implementatiewijzigingen, omdat Auth0 deze voor u regelt.


Leer hoe u Auth0 Lock gebruikt in zowel web- als native apps. Bekijk ook onze quickstarts.


Om aan de slag te gaan met moderne authenticatie, biedt Auth0 een aanzienlijk gratis niveau.


Conclusie


Het overschakelen van ingebedde browsers kan tijdrovend zijn, maar heeft een aanzienlijk gebruikersvoordeel. Omdat klanten die al zijn geregistreerd bij Google, zich met één druk op de knop bij uw app kunnen aanmelden, zou dit de conversieratio van uw aanmeldingsstroom moeten verhogen. Bovendien zullen gebruikers een vlotte inlogervaring hebben, omdat degenen die niet zijn ingelogd, moeten inloggen bij Google voor de eerste app die ze gebruiken, maar niet opnieuw hoeven in te loggen voor toekomstige apps.Als er een probleem is, neem dan contact met mij op via Google Bellen.


2 views0 comments
bottom of page