Sikre WebViews Med Chrome Custom Tabs

Plaid utdanner innovatører i fintech plass ved å gi dem tilgang til økonomiske data via en enhetlig API. For å hjelpe sluttbrukere koble sine bankdata til fintech apps, Plaid utviklet Link, en drop-in modul som håndterer legitimasjon validering, multi-faktor autentisering, og feilhåndtering for hver støttet bank.

Android-utviklere måtte tidligere åpne Koblingsadresser i WebViews. Hver app som ønsket Å bruke Link krevde mye utviklerinnsats, og uten standardisering var det bundet til å være feil i noen av implementeringene. For å forbedre utvikleropplevelsen, har vi nylig gitt ut EN SDK som gjør WebView enkelt å integrere i en hvilken som helst app med noen få linjer med kode.

I Tillegg Er WebViews ikke helt sikre for sluttbrukere som legger inn sensitiv informasjon i Koblingsflyten. FOR å gjøre VÅR SDK så sikker som mulig, har vi implementert Den ved Hjelp Av Chrome tilpassede faner i stedet For Android WebViews. I denne artikkelen forklarer vi hvorfor vi har tatt den beslutningen og hvordan vi har overvunnet de tekniske problemene vi opplevde underveis.

Evaluering Av Våre Alternativer

SOM EN SDK, kjører koden vår i andre utviklernes applikasjoner, og i sin tur deres applikasjonsprosesser. For å kjøre Link web app i En WebView, Må Javascript være aktivert. Dette åpner døren for at andre apper kan kjøre skadelig kode, for eksempel registrering av tilbakeringinger som prøver å fange opp brukernavn og passord. I tillegg kan en skadelig app åpne en annen nettside som etterligner Koblingsflyten i et phishing-forsøk.

når vi lette etter en løsning som er enkel å integrere med for utviklere, intuitiv for sluttbrukere og sikker, vurderte vi flere alternativer:

1. bygge en native link flow: fordi native Link flyter vil også kjøre i en annen app prosess, kunnskapsrike utviklere kan bruke refleksjon for å finne våre innspill EditTexts og registrere tilbakeringinger på en måte som Ligner På Javascript I En WebView.

2. bygge en egen autentiseringsapp: Dette ville gi en innfødt sandkasseopplevelse og ville være en ideell opplevelse for sluttbrukere; mange brukere vil imidlertid ikke laste ned en ekstra app fra Play-Butikken. Dette betyr at vi trenger en reserveløsning for brukere som nekter å laste ned appen.

3. åpning Lenke i et eget nettleservindu: Dette ville være en sandkasse, sikker løsning. Nesten alle brukere har en nettleser installert, men konteksten som bytter fra en app til en nettleser, vil introdusere en merkbar forsinkelse, spesielt på low-end-enheter.

4. Bruke Tilpassede Faner I Chrome: Dette er løsningen vi valgte, da det ikke hadde noen av ulempene nevnt ovenfor.

Vårt Valg: Chrome Custom Tabs

Chrome custom tabs (Cct) er en del Av Chrome-nettleseren som integreres Med Android framework for å tillate apper å åpne nettsteder i en lett prosess. CCT åpnes raskere enn en nettleser, og hvis forhåndslastet via oppvarmingsanropet, er det potensielt enda raskere enn En WebView. Mens Det fortsatt kjører Javascript, er Det i sin egen prosess, som forhindrer at apper kjører skadelig kode. Videre gir CCT UI en handlingslinje som viser NETTADRESSEN til siden som lastes, sammen med ET SSL-verifikasjonslåsikon for sikre sider. Dette forsikrer brukerne om at den riktige siden blir vist.

Selv om Ikke Alle Brukere Har Chrome installert, gjør de aller fleste. For de som ikke gjør det, bruker vi nettleserens reservemetode beskrevet ovenfor (alternativ 3); annet enn å legge til en linje med kode, får vi reserven gratis fra CCT. Som nevnt før, er nettleserens fallback ikke den ideelle brukeropplevelsen på grunn av latens, men det opprettholder det høye sikkerhetsnivået Som Plaid krever.

Da VI utviklet CCT-løsningen, løp vi inn i og adresserte flere komplikasjoner:

• Få hendelsesdata

• Henter det endelige resultatet

• Kontrollere CCT-aktiviteten & – prosessen

Få Hendelsesdata

når en bruker navigerer mellom skjermer I Link, skjer en viderekobling og data gis til utviklere I URL-parametrene.

denne omdirigere informasjon er verdifull for utviklere, som det hjelper dem å forstå brukeradferd. MED CCT som kjører i sin egen prosess og ikke gir en omdirigering, vil denne informasjonen normalt være utilgjengelig, noe som vil gjøre vår sikre SDK mindre funksjonell for utviklere enn deres tilpassede WebView-implementeringer.

for å gi denne informasjonen fra CCT, registrerte vi i stedet omdirigeringshendelsene på serveren i En Redis datastore. NÅR SDK åpner Link, det gjør en bootstrap samtale til våre servere, som gir en per-bruker kanal ID valgt av oss og en hemmelig nøkkel. SDK oppretter deretter en app-scoped worker objekt, som avstemninger serveren ved hjelp AV EN rx intervall stream. På hvert valgkall gir vi serveren kanal-ID, hemmelig nøkkel og DEN siste hendelsens UUID (eller null) for å få de siste hendelsene.

 
 Observerbar.intervall (intervall, Tidsenhet.SEKUNDER) 
 
 .subscribeOn (Planleggere.beregning()) 
 
 .observeOn (AndroidSchedulers.mainThread()) 
 
 .flatMapSingle(makeNetworkCall)()) 
 
 .abonner( 
 
 { 
 
 // Håndtere meldinger 
 
 }, 
 
 { 
 
 // Håndter feil 
 
 }) 
 
 

Android-rammeverket kan drepe enhver prosess, inkludert appen ved HJELP Av Plaids SDK. Siden arbeiderobjektet er knyttet til programmet, vil dette føre til at arbeideren stoppes. HVIS brukeren fortsatte flyten, (enten vellykket eller uten hell) SDK ville gjøre en siste samtale til kanalen og få de resterende hendelsene. Hendelser vil bare gå tapt hvis brukeren avbrutt flyt og kraft drept app.

Henter Det Endelige Resultatet

I Likhet med å sende hendelsesdata til klienter, Bruker Link URL-ADRESSEN til å signalisere at brukeren har fullført flyten. DEN relevante NETTADRESSEN inneholder nødvendige data, for eksempel den offentlige nøkkelen eller en feilkode.

siden VI ikke får TILGANG TIL NETTADRESSEN MED CCT, lagret vi sluttresultatet I Redis med samme kanal-ID. Selv om dette betyr at vår meningsmålingsarbeider ville vite når Link er ferdig, ville det ikke være noen garanti for at arbeideren fortsatt ville være i live. Selv om det var i live, må brukeren kanskje vente til neste valgkall for at resultatet skal leveres, noe som kan være et langt par sekunder.

for å sikre at et resultat blir levert i tide, bruker vi en dyp kobling for å gjenåpne SDK. Den dype koblingen er konstruert ved hjelp av programmets app-ID, som må være knyttet til klientens hemmelighet og hvitelistet på utviklerens dashbord. Dette, pluss det faktum at bare en app på en enhet kan ha samme app-ID, sikrer at ingen andre apper avskjærer omdirigeringen. Link web app bygger deretter en intent URI, som er sparket på slutten Av Linkflyten.

 
intent:/ / redirect / # Intent; scheme=plaid; pakke=$packageName; slutt;
 
 

VÅR SDK inneholder et intentfilter for å håndtere URI, slik at programmet åpnes og ringer direkte til kanalen umiddelbart.

 
 <intent-filter> 
 
 <handling android: navn= " android.hensikt.handling.SE" /> 
 
 
 
 <kategori android: name= " android.hensikt.kategori.STANDARD" /> 
 
 <kategori android: name= " android.hensikt.kategori.SØKBAR" /> 
 
 
 
 <data 
 
 android: host= "viderekobling" 
 
 android:skjema= "plaid" /> 
 
 </intent-filter> 
 
 

Kontrollere CCT

CCT mangler grensesnitt for appen til:

• lytt etter når brukeren lukker aktiviteten

• oppdage når brukeren har klikket på» Åpne I Nettleseren » alternativet

• tvinge den til å lukke

vi har med hell jobbet rundt alle disse manglene.

først, for å lytte etter når brukeren lukker aktiviteten, åpner VI CCT ved hjelp av startActivityForResult og sender den en forespørselskode. Hvis brukeren lukker CCT ved Hjelp Av X i øvre venstre hjørne av system tilbake-knappen, utløses onActivityResult tilbakeringing med forespørselskoden vi ga og en resultatkode For Aktivitet.RESULTAT_CANCELED. Dataintensjonen inneholder ingen informasjon, men vi kan ta en siste samtale til kanalen for å få de resterende hendelsene. Vi sender dem deretter til klientappen og returnerer Et LinkCancellation-objekt, som signaliserer At Lenken ble lukket med vilje av brukeren.

neste, den potensielle bekymring med å oppdage når brukeren har klikket «Åpne I Nettleseren» er at brukeren kan da gå gjennom hele flyten i et eget program, nemlig nettleseren. Dette er ikke et problem for oss, fordi valg-og intensjonssystemene fortsetter å fungere på samme måte, og vi kan fortsatt få de dataene som trengs.

TIL Slutt, når brukeren fullfører flyten vellykket og resultatet hensikt er avfyrt, CCT prosessen vil forbli åpen og i brukerens oppgaveliste. Denne fantomprosessen ville ikke bare være sløsing, men kan også være forvirrende for en bruker når de trykker på systemknappen «nylige oppgaver». Derfor trenger vi en måte å tvinge CCT til å lukke når strømmen er fullført.

for å gjøre dette, brukte vi mønsteret som vises I OpenId AppAuth For Android biblioteket. I stedet for å håndtere resultatet i aktiviteten som åpner Koblingen, plasserer vi intensjonsfilteret på en egen aktivitet. Denne andre aktiviteten håndterer alle omdirigeringer fra web app, som inkluderer: vellykkede fullføringer, feil som lukker flyten, oauth eller App-Til-App omdirigeringer, og generelle systemfeil. Aktiviteten sender deretter dataene tilbake til åpningsaktiviteten ved hjelp av en hensikt med Hensikten.FLAG_ACTIVITY_SINGLE_TOP Og Hensikt.FLAG_ACTIVITY_CLEAR_TOP flagg. Brukes sammen, fjerner de alt på stakken over åpningsaktiviteten, inkludert CCT.

 
 
 val intent = Intent (aktivitet, Linkaktivitet:: klasse.java) 
 
 når (stat) { 
 
 Er RedirectState.ChromeCustomTabsComplete -> { 
 
 hensikt.putExtra (LINK_CHROME_CUSTOM_TABS_COMPLETE_REDIRECT, true) 
 
 hensikt.putExtra(LINK_RESULT_CODE, state.resultCode) 
 
 intent.putExtra(LINK_RESULT, state.result) 
 
 } 
 
 is RedirectState.UserInitiatedChromeCustomTabsViewClose -> { 
 
 intent.putExtra(LINK_CHROME_CUSTOM_TABS_USER_CLOSE_REDIRECT, true) 
 
 } 
 
 is RedirectState.OAuth -> { 
 
 intent.putExtra(LINK_OAUTH_REDIRECT, true) 
 
 intent.putExtra(LINK_OAUTH_STATE_ID, state.oauthStateId) 
 
 } 
 
 is RedirectState.RedirectError -> 
 
 intent.putExtra (LINK_REDIRECT_ERROR, sant) 
 
 } 
 
 hensikt.flagg = Hensikt.FLAG_ACTIVITY_SINGLE_TOP eller Hensikt.FLAG_ACTIVITY_CLEAR_TOP 
 
 retur hensikt 
 
 

Avsluttende tanker OM CCT

FOR å gi en sikker, sandkasseopplevelse som ikke er tilgjengelig I WebViews eller innfødte strømmer, ER CCT en levedyktig løsning. Det er lett å integrere med for utviklere og gir en bedre brukeropplevelse enn å åpne nettleservinduer takket være sin lette natur og hastighet.

CCT er sandboxed natur og begrenset API mener det er ikke uten sine ulemper. Lytte TIL URL viderekoblinger, få endelige resultater og kontrollere CCT prosessen alle krevde oss til å komme opp med kreative løsninger. Disse løsningene stod på en forståelse Av Androids innebygde funksjoner, spesielt intent framework.

fordelene for utviklere og forbrukere var vel verdt den nødvendige innsatsen, og vi anbefaler å bruke CCT i andre apper og Sdk-Er for en rask og sikker integrasjon. Videre kan du bruke tipsene som er gitt her for å forbedre brukeropplevelsen (og utvikleren).

hvis du er interessert i å løse unike problemer som vil bli brukt av tusenvis av utviklere og millioner av forbrukere, besøk vår karriere side.