API AUTENTIFIKACIJA

Saugumo reikalavimai API autentifikacijai

Praktinis vadovas apie OAuth 2.0 ir JWT tokeno naudojimą. Kaip apsaugoti bankinę informaciją API sąsajose nuo neautorizuoto prieigos ir duomenų nuotolio.

12 min skaitymo Vidutinis lygis Liepa 2026

Saugumo sistemos diagrama su užraktu ir tinkleliu ant kompiuterio ekrano

FinTech Bridge Redakcija

Redakcinė komanda

Parengta FinTech Bridge redakcinės komandos, sutelktos į praktines, lengvai suprantamas gaires banko ir ERP integracijos klausimais.

Kodėl autentifikacija yra kritinė?

API autentifikacija yra pirmas saugumo sluoksnis. Jei jį nesutvarkytumėte teisingai, neleistinas asmuo galėtų pasiekti bankinę informaciją ir vykdyti operacijas jūsų vardu. Tai nėra abstrakcija — tai realus grėsmė.

Bet jei žinote, kaip teisingai nustatyti OAuth 2.0 ir JWT, jūs galite sukurti saugias sąsajas, kuriose tiek bankai, tiek jūs būsite linksmi. Šis vadovas paaiškina, kaip tai daryti žingsnis po žingsnio.

Kompiuterio ekrane rodomą saugumo šifravimo sistemos schema

OAuth 2.0 autentifikacijos proceso diagramos pavyzdys

OAuth 2.0: Standartinis pasirinkimas

OAuth 2.0 yra tarpbankinės autentifikacijos standartas. Tai reiškia, kad jūs neklausiate banko slaptažodžio. Vietoje to, naudotojas eina į banko sistemą, suteikia leidimą, ir jūs gausite specialų žetoną (token).

Tas žetons leidžia jums prieiti prie duomenų ir vykdyti operacijas, bet tik tam, ką jūs nustatėte. Jei naudotojas atšaukia leidimą, žetons dingsta. Paprasta, bet galingai.

Naudotojas nori jungti banką

Jis spaudžia "Susieti banką" mygtuką jūsų sistemoje.

Peradresavimas į banką

Jūsų sistema nukreipia jį į banko autoruzacijos langą su jūsų client_id.

Suteikimas ir peradresavimas

Naudotojas sutinka ir grįžta pas jus su autorizacijos kodu.

Žetono mainai

Jūsų serveris siunčia kodą bankui ir gauna access_token bei refresh_token.

JWT žetonai: Saugūs ir kompaktiški

JWT (JSON Web Token) — tai koduotas žetons, kuris saugo informaciją. Kai jūs gaunate JWT iš banko, jūs nematote jo vidinės struktūros, bet serveris gali jį iššifruoti ir pamatyti, kas tai yra. Tai daroma su slaptu raktu, kurį tik jūs ir bankas žinote.

JWT turi tris dalis: antraštė (header), apkrova (payload) ir parašas (signature). Antraštė sako, kokias šifrą naudoti. Apkrova saugo faktinę informaciją — kas tai, kada baigs galioti, ir ką galima daryti. Parašas užtikrina, kad niekas nepakeitė žetono kelyje.

JWT galiojimo laikas — kritinis

Jūs negalite tiesiog naudoti JWT amžinai. Jis turi galiojimo laiką (exp claim). Dažniausiai tai 15 minučių arba 1 valanda. Pasibaigus laikui, žetons nustoja veikti ir reikia prašyti naujo. Tai apsaugo nuo to, kad pavogtą žetoną galima būtų naudoti be galo.

JWT žetono struktūros vizualinis pavaizdavimas su antrašte, apkrova ir parašu

Praktiniai saugumo nustatymai

Slapti raktai apsaugoti

Jūsų client_secret niekada nesiųsti į naršyklę. Jis lieka tik jūsų serveryje. Kai kurie žmonės šią taisyklę laužo ir viską pataiso vėliau. Jūs to nedarykite.

HTTPS tik

Visos API sąsajos su banku turi būti per HTTPS. HTTP yra pavojinga. Žetonai ir duomenys gali būti perimti. Bankai to tiesiog neleidžia — jie atmes bet kokį HTTP užklausą.

Galiojimo laikas (TTL)

Nustatykite access_token galiojimo laiką nuo 15 minučių iki 1 valandos. Refresh_token gali galioti 30 dienų. Trumpesnis laikas = daugiau saugumo, bet daugiau užklausų.

Scopes ir ribos

Prašykite tik tų teisių, kurias jūs tikrai reikalingos. Naudotojas gali suteikti tik čitanimas (read) leidimą, be rašymo (write). Taikyti tai, ką reikalaujate.

Žetono atnaujinimas

Kada access_token baigiasi, naudokite refresh_token, kad gautumėte naują. Naudotojas neturi grįžti į banką. Jis automatinis, bet saugus procesas.

Klaidų tvarkymas

Jei naudotojas atšaukia leidimą arba žetons negalioja, nesiųskite duomenų. Grąžinkite klaidą ir nukreipkite jį iš naujo autentifikuoti. Tai paaiškinta, bet saugi.

Saugumo patikrinimo proceso schema su šifravo ir žetono validacijos

Programavimo kodo fragmentas su OAuth 2.0 integracijos pavyzdžiu

Nuo teorijos prie praktikos

Dabar, kai jūs žinote, kaip OAuth 2.0 ir JWT veikia, laikas nustatyti. Pirma, registruokitės banko API portale. Jie suteiks jums client_id ir client_secret. Saugokite secret — jei kas nors jį gaus, gali pretenzduoti būti jūs.

Tada nustatykite redirect_uri. Tai yra adresas, į kurį bankas grąžins naudotoją po autentifikacijos. Jis turi sutapti su tuo, ką bandote — ne, jei bandote iš localhost, bankas gali neleisti. Kai kurių bankų šiuose klausimais labai griežtos.

Trečia, implementuokite OAuth srautą jūsų programoje. Jūsų backend serveris turi dalykus tvarkyti. Nesiuntinėkite client_secret į naršyklę. Jei jūs tai darote, turite rimtą saugumo problemą ir ją reikia taisyti dabar.

Daži klaidų patrulėjimai:

Client_secret yra šaltasis kodas (hardcoded) naršyklėje — tai klaidai
Neatnaujinamas žetons — naudotojas jį gali atšaukti ir sistema sutrinka
Nėra galiojimo laiko JWT — žetons galioja amžinai
Nėra verififikavimo banko parašo — jūs priimate bet kokį žetoną
HTTP vietoje HTTPS — žetonai gali būti perimti

Baigiamosios mintys

API autentifikacija nėra sudinga, kai jūs suprantate pagrindinius principus. OAuth 2.0 ir JWT — tai industrijos standartai, nes jie veikia. Jie suteikia jums saugumą ir patogumo.

Jūs negalite pakeisti to, kad bankai yra griežti šiais klausimais. Bet tai geras dalykas. Tai reiškia, jei jūs tinkamai nustatysite, jūsų sistema bus saugi. Ir saugumas yra labai svarbus, kai kalbame apie pinigus.

Norėdami pagilinti žinias, skaitykite mūsų kitus straipsnius apie REST API ir ERP integracijas. Jie papildo šią informaciją ir padeda viską susieti.

Svarbi informacija

Šis straipsnis skirtas edukaciniam tikslui — padėti jums suprasti API autentifikacijos principus. Jis nėra konkretus saugumo audit arba juridinis patarimas. Kiekvienas bankas turi savus saugumo reikalavimus ir standartus. Prieš diegiant sistemą su banka, būtinai patikrinkite jų technines specifikacijas ir saugumo dokumentaciją. Konsultuokitės su banko integracijos komanda ir saugumo specialistais, jei turite klausimų dėl jūsų konkrečios implementacijos.

Susiję straipsniai

Šiuolaikinis biuro stalas su kompiuteriu ir API dokumentacija