sikring af Internetvisninger med Chrome Custom Tabs

Plaid giver innovatører i fintech-rummet mulighed for at give dem adgang til økonomiske data via en ensartet API. For at hjælpe slutbrugere med at forbinde deres Bankdata til fintech-apps udviklede Plaid Link, et drop-in-modul, der håndterer validering af legitimationsoplysninger, multifaktorautentificering og fejlhåndtering for hver understøttet bank.

Android-udviklere måtte tidligere åbne Link-URL ‘ er i Internetvisninger. Hver app, der ønskede at bruge Link, krævede en masse udviklerindsats, og uden standardisering var der sandsynligvis fejl i nogle af implementeringerne. For at forbedre udvikleroplevelsen frigav vi for nylig en SDK, der gør Internetvisningen let at integrere i enhver app med et par linjer kode.

derudover er Internetvisninger ikke helt sikre for slutbrugere, der indtaster følsomme oplysninger i Linkstrømmen. For at gøre vores SDK så sikker som muligt, har vi implementeret det ved hjælp af Chrome brugerdefinerede faner i stedet for Android-Internetvisninger. I denne artikel forklarer vi, hvorfor vi har taget denne beslutning, og hvordan vi har overvundet de tekniske problemer, vi stødte på undervejs.

evaluering af vores muligheder

som SDK kører vores kode inden for andre udvikleres applikationer og til gengæld deres applikationsprocesser. For at kunne køre Link-appen i en visning, skal Javascript være aktiveret. Dette åbner døren for andre apps til at køre ondsindet kode, såsom registrering af tilbagekald, der forsøger at opfange brugernavne og adgangskoder. Derudover kan en ondsindet app åbne en anden hjemmeside, der efterligner Linkstrømmen i et phishing-forsøg.

når vi ledte efter en løsning, der er let at integrere med for udviklere, intuitiv for slutbrugere og sikker, vurderede vi flere muligheder:

1. opbygning af en indbygget linkstrøm: fordi indfødte Linkstrømme også ville køre i en anden apps proces, kunne kyndige udviklere bruge reflection til at finde vores inputredigeringer og registrere tilbagekald på en måde, der ligner Javascript i en Internetvisning.

2. opbygning af en separat authenticator app: Dette ville give en indfødt sandkasse oplevelse og ville være en ideel oplevelse for slutbrugere; imidlertid, mange brugere ønsker ikke at hente en ekstra app fra Play Butik. Det betyder, at vi ville have brug for en fallback løsning for brugere, der nægter at hente app.

3. åbning Link i en separat bro. ser vindue: Dette ville være en sandkasse, sikker løsning. Næsten alle brugere har en bro. ser installeret, men konteksten, der skifter fra en app til en bro.ser, vil introducere en mærkbar forsinkelse, især på lave enheder.

4. brug af Chrome Brugerdefinerede faner: Dette er den løsning, vi valgte, da den ikke havde nogen af de ulemper, der er nævnt ovenfor.

vores valg: Chrome Custom Tabs

Chrome custom tabs (CCT) er en del af Chrome, der integreres med Android-rammen for at give apps mulighed for at åbne hjemmesider i en letvægtsproces. CCT åbner hurtigere end en bro.ser og, hvis forudindlæst via sin opvarmning opkald, er potentielt endnu hurtigere end en Internetvisning. Mens det stadig kører Javascript, er det i sin egen proces, som forhindrer apps i at køre ondsindet kode. Desuden giver CCT-brugergrænsefladen en handlingslinje, der viser URL ‘ en til den side, der indlæses, sammen med et SSL-verifikationslåsikon for sikre sider. Dette forsikrer brugerne om, at den rigtige side vises.

selvom ikke alle brugere har Chrome installeret, gør langt de fleste det. For dem, der ikke gør det, bruger vi fallback-metoden beskrevet ovenfor (mulighed 3); bortset fra at tilføje en linje kode, får vi fallback gratis fra CCT. Som tidligere nævnt er fallback ikke den ideelle brugeroplevelse på grund af dens latenstid, men det opretholder det høje sikkerhedsniveau, som Plaid kræver.

da vi udviklede CCT-løsningen, løb vi ind i og behandlede flere komplikationer:

• Hent hændelsesdata

• henter det endelige resultat

• styring af CCT-aktiviteten & – processen

Hent hændelsesdata

når en bruger navigerer mellem skærme i Link, sker der en omdirigering, og data leveres til udviklere i URL-parametrene.

disse omdirigeringsoplysninger er værdifulde for udviklere, da det hjælper dem med at forstå brugeradfærd. Når CCT kører i sin egen proces og ikke giver en omdirigering tilbagekald, vil disse oplysninger normalt være utilgængelige, hvilket ville gøre vores sikre SDK mindre funktionel for udviklere end deres brugerdefinerede implementeringer.

for at give disse oplysninger fra CCT registrerede vi i stedet omdirigeringshændelserne på serveren i en Redis datastore. Når SDK åbner Link, det gør en bootstrap opkald til vores servere, som giver en per-bruger kanal ID valgt af os og en hemmelig nøgle. SDK opretter derefter et app-scoped arbejderobjekt, som afstemmer serveren ved hjælp af en rk-intervalstrøm. På hvert valgopkald giver vi serveren kanal-ID, hemmelig nøgle og den sidste begivenheds UUID (eller null) for at få de seneste begivenheder.

 
 observerbar.interval (interval, Tidenhed.Sekunder) 
 
.subscribeOn (planlæggere.beregning()) 
 
 .observeOn (AndroidSchedulers.mainThread()) 
 
 .flatMapSingle (makenetværkcall()) 
 
 .Tilmeld( 
 
 { 
 
 // Håndter meddelelser 
 
 }, 
 
 { 
 
 // Håndter fejl 
 
 }) 
 
 

Android-rammen kan dræbe enhver proces, herunder appen ved hjælp af Plaid ‘ s SDK. Da arbejdstagerobjektet er bundet til applikationen, vil dette resultere i, at arbejdstageren stoppes. Hvis brugeren fortsatte strømmen (enten med succes eller uden succes), ville SDK foretage et sidste opkald til kanalen og få de resterende begivenheder. Begivenheder ville kun gå tabt, hvis brugeren afbrød strømmen og kraften dræbte appen.

henter det endelige resultat

i lighed med at overføre hændelsesdata til klienter bruger Link URL ‘ en til at signalere, at brugeren har afsluttet forløbet. Den relevante URL indeholder nødvendige data, såsom den offentlige nøgle eller en fejlkode.

da vi ikke kan få adgang til URL ‘ en med CCT, lagrede vi det endelige resultat i Redis med samme kanal-ID. Selvom dette betyder, at vores valgmedarbejder ville vide, hvornår Link er færdig, ville der ikke være nogen garanti for, at arbejdstageren stadig ville være i live. Selvom det var i LIVE, skal brugeren muligvis vente til det næste valgopkald for at resultatet skal leveres, hvilket kan være et langt par sekunder.

for at sikre, at et resultat leveres rettidigt, bruger vi et dybt link til at genåbne SDK. Deep link er konstrueret ved hjælp af programmets app-ID, som skal være forbundet med klienthemmeligheden og hvidlistet på udviklerens dashboard. Dette plus det faktum, at kun en app på en enhed kan have det samme app-ID, sikrer, at ingen andre apps opfanger omdirigeringen. Link-appen bygger derefter en intent URI, der fyres i slutningen af Linkstrømmen.

 
hensigt: / / omdirigering/ # hensigt; ordning=plaid; pakke= $ Pakkenavn; ende;
 
 

vores SDK indeholder en hensigt filter til at håndtere URI, så programmet genåbner og foretager et opkald direkte til kanalen med det samme.

 
 <intent-filter> 
 
 <Handling android: name= " android.hensigt.handling.Se" /> 
 
 
 
 <kategori android: name= " android.hensigt.kategori.Standard" /> 
 
 <kategori android: name= " android.hensigt.kategori.Kan gennemses" /> 
 
 
 
 <data 
 
 android: host= "redirect" 
 
 android:scheme= "plaid" /> 
 
 </intent-filter> 
 
 

kontrol af CCT

CCT mangler grænseflader til appen til:

• lyt efter, når brugeren lukker aktiviteten

• find ud af, hvornår brugeren har klikket på indstillingen ” Åbn i

• tving det til at lukke

vi har med succes arbejdet omkring alle disse mangler.

for det første at lytte til, når brugeren lukker aktiviteten, åbner vi CCT ved hjælp af startActivityForResult og sender den en anmodningskode. Hvis brugeren lukker CCT ved hjælp af H i øverste venstre hjørne af Systemback-knappen, udløses onactivityresultat-tilbagekaldelsen med den anmodningskode, vi har angivet, og en resultatkode for aktivitet.RESULT_CANCELED. Dataintentionen inkluderer ingen oplysninger, men vi kan foretage et sidste opkald til kanalen for at få de resterende begivenheder. Vi sender dem derefter til klientappen og returnerer et LinkCancellation-objekt, hvilket signaliserer, at linket blev lukket med vilje af brugeren.

dernæst er den potentielle bekymring med at opdage, når brugeren har klikket på” Åbn i Bro.ser”, at brugeren derefter kunne gennemgå hele strømmen i en separat applikation, nemlig bro. ser. Dette er ikke et problem for os, fordi afstemnings-og intentionssystemerne fortsætter med at fungere på samme måde, og vi kan stadig få de nødvendige data.

endelig, når brugeren fuldfører forløbet med succes og resultatet hensigt er fyret, vil CCT processen forblive åben og i brugerens opgaveliste. Denne fantomproces ville ikke kun være spildt, men kunne også være forvirrende for en bruger, når de trykker på systemknappen “seneste opgaver”. Derfor har vi brug for en måde at tvinge CCT til at lukke, når strømmen er færdig.

for at gøre dette brugte vi mønsteret vist i OpenID AppAuth til Android-biblioteket. I stedet for at håndtere resultatet i den aktivitet, der åbner Link, placerer vi intentionsfilteret på en separat aktivitet. Denne anden aktivitet håndterer alle omdirigeringer fra internettet app, som omfatter: succesfulde færdiggørelser, fejl, der lukker strømmen, OAuth eller app-til-app omdirigeringer og generelle systemfejl. Aktiviteten sender derefter dataene tilbage til åbningsaktiviteten ved hjælp af en hensigt med hensigten.FLAG_ACTIVITY_SINGLE_TOP og hensigt.FLAG_ACTIVITY_CLEAR_TOP flag. Brugt sammen rydder de alt på stakken over åbningsaktiviteten, herunder CCT.

 
 
 val intent = Intent (aktivitet, LinkActivity:: klasse.java) 
 
 hvornår (tilstand) {
 
 er Omdirigeretstate.ChromeCustomTabsComplete -> { 
 
 hensigt.putekstra (LINK_CHROME_CUSTOM_TABS_COMPLETE_REDIRECT, sand) 
 
 intent.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.putekstra (LINK_REDIRECT_ERROR, sand) 
 
 } 
 
 hensigt.flag = hensigt.FLAG_ACTIVITY_SINGLE_TOP eller hensigt.FLAG_ACTIVITY_CLEAR_TOP 
 
 retur hensigt 
 
 

Endelige tanker om CCT

for at give en sikker, sandkasseoplevelse, der ikke er tilgængelig i Internetvisninger eller indfødte strømme, er CCT en levedygtig løsning. Det er nemt at integrere med for udviklere og giver en bedre brugeroplevelse end at åbne vinduer takket være dens lette natur og hastighed.

CCT ‘ s sandkasse natur og begrænset API betyder, at det ikke er uden sine ulemper. At lytte til URL-omdirigeringer, få endelige resultater og kontrollere CCT-processen krævede alle, at vi kom med kreative løsninger. Disse løsninger var afhængige af en forståelse af Android ‘ s indbyggede funktioner, især intentionsrammen.

fordelene for udviklere og forbrugere var den krævede indsats værd, og vi anbefaler at bruge CCT i andre apps og SDK ‘ er til en hurtig og sikker integration. Desuden kan du bruge tipene her til at forbedre brugeroplevelsen (og udvikleren).

hvis du er interesseret i at løse unikke problemer, der vil blive brugt af tusindvis af udviklere og millioner af forbrugere, kan du besøge vores karriere side.