Jak się uchronić przed blokowaniem OAuth przez Google

Już w najbliższy czwartek (20.04.2017) Google zablokuje “logowanie” przy pomocy protokołu OAuth 2.0 w niektórych aplikacjach mobilnych. Zmiany te wynikają z opublikowanego już w sierpniu 2016 roku wpisu o zwiększeniu przez firmę poziomu bezpieczeństwa i wygody obsługi aplikacji. Wpis można znaleźć na blogu Google Developers. Poniżej opiszę jak się uchronić przed blokowaniem OAuth przez Google, nie zabraknie również części poświęconej wymaganym zmianom w Azure AD B2C.

Jakie aplikacje narażone są na problemy?

Z opublikowanego komunikatu wynika, że wszystkie aplikacje mobilne, które podczas uwierzytelniania i autoryzacji do kont Google używają natywnej kontrolki WebView (a konkretnie WebView w Android, UIWebView w iOS, WebView w Windows Phone itp) nie będą w stanie od czwartku wykonać tego typu operacji. W efekcie użytkownicy wspomnianych aplikacji pozbawieni zostaną możliwości logowania do swojego konta. To z kolei może przełożyć się na sporo innych komplikacji.

Podobnie sprawa wygląda w przypadku Azure AD B2C, które przez długi okres (do marca 2017) wspierało tylko taką formę procesu uwierzytelniania i autoryzacji. Praktycznie każda aplikacja B2C/Google+ jest potencjalnie narażona na problemy, jeżeli nie wdrożymy wymaganych poprawek. Na liście są aplikacje stworzone przy pomocy Xamarin, aplikacje używające MSAL’a, bibliotek ADAL, OIDCAndroidLib lub NXOAuth2Client.

Jakie zmiany musisz wdrożyć, by Twoja aplikacja dalej działała?

Ten fragment przeznaczony jest oczywiście dla wydawców i twórców aplikacji mobilnych. Jako użytkownik musisz cierpliwie poczekać na nową wersję aplikacji, która pewnie będzie musiała przejść długotrwały proces weryfikacji.

W klasycznym rozwiązaniu aplikacja, kiedy chce zalogować użytkownika poprzez Google, tworzy kontrolkę WebView, wysyłając go na adres logowania. Po zakończonym logowaniu IdP (Identity Provider) przekierowuje żądanie na ustalony wcześniej adres – w przypadku B2C i rozwiązań native client jest to zwykle:

urn:ietf:wg:oauth:2.0:oob

Aplikacja oczekuje w WebView na określone przekierowanie, odbiera i weryfikuje token z odpowiedzią kończąc w ten sposób proces logowania. W nowym procesie nie możemy użyć WebView i musimy opuścić na chwilę aplikację uruchamiając żądanie w przeglądarce systemowej. Proces przebiega podobnie, ale pojawia się jedna trudność. Skąd przeglądarka systemowa (np Chrome czy Safari) ma wiedzieć, że po otrzymaniu umówionego przekierowania ma oddać sterowanie z powrotem do naszej aplikacji? Możemy w tym miejscu użyć niestandardowych URN, przykładowo:

com.grabarze.marek.myapp://loginredirect

W naszej aplikacji nasłuchujemy (przykład w iOS) na ten właśnie URN (pamiętaj, że pierwsza część to właśnie nazwa aplikacji) i po otrzymaniu przekierowania dalszy proces przebiega identycznie.

Pozostaje nam już tylko temat B2C i jak skonfigurować usługę, by dla naszej aplikacji dopuszczała niestandardowy URN. We właściwościach aplikacji pojawiła się jakiś czas temu nowa opcja, dzięki której takie ustawienie jest możliwe:

Ostatnia rzecz to zabezpieczenie się przed sytuacją,  kiedy inna aplikacja próbuje podkraść odpowiedź dotyczącą naszej próby logowania z przeglądarki. Możemy się przed takim zdarzeniem uchronić dzięki “pixy” Proof Key for Code Exchange. W skrócie generujemy kod, który wysyłany jest wraz z żądaniem, tylko dzięki niemu możemy odszyfrować odpowiedź.

Kilka słów wyjaśnienia

W powyższym tekście pojawiło się sporo technicznych pojęć, jeżeli cokolwiek sprawiło Ci trudność, umieść proszę swoje pytania w komentarzach, postaram się na nie w miarę możliwości odpowiedzieć.

Nie śledzę na bieżąco ogłoszeń dotyczących OAuth, na szczęście mogę zawsze w tym temacie liczyć na Tomasza Onyszko, polskiego eksperta w dziedzinie bezpieczeństwa i tożsamości. Bez niego pewnie bym się dowiedział o powyższych zmianach w czwartek i miał sporo pracy do zrobienia po godzinach.