e-Identitātes platformas pamati

Pakalpojuma sniedzēja lietojumprogrammai ir jāizmanto API atslēga kā autentifikācijas rekvizīti katrā pieprasījumā, ko tā nosūta autentifikācijas un autorizācijas pakalpojumam, lai iegūtu piekļuves pilnvaru jebkuram platformas aizsargātajam resursam. Lai to izdarītu, saskaņā ar OAuth 2.0 specifikāciju, pakalpojumu sniedzēja lietojumprogrammai ir jāievieto API atslēga šo pieprasījumu autorizācijas galvenē, kā norādīts tālāk.

Authorization: Basic <API-Key>

API piekļuves atslēgas pamati

Pirms pakalpojumu sniedzējs piekļūst Integrācijas platformas API, LVRTC reģistrē pakalpojumu sniedzēju kā Integrācijas platformas klientu.

Pēc līguma noslēgšanas ar LVRTC (testa vai produkcijas vidē) LVRTC ģenerē pakalpojumu sniedzēja lietotnes identifikatoru — client_id un koplietojamo slepeno atslēgu client_secret, kas paredzēti klienta lietošanai.

API piekļuves atslēga (API Key) tiek ģenerēta no pakalpojuma sniedzēja lietojumprogrammas identifikatora client_id, slepenas atslēgas, kas kopīgota ar platformu client_secret pamatojoties uz šādiem principu

Pakalpojuma sniedzēja lietojumprogrammas identifikators client_id tiek konvertēts, izmantojot UTF-8 rakstzīmju kodējumu un URL kodēšanas nosacījumus.

Pakalpojuma sniedzēja lietojumprogrammas parole client_secret tiek konvertēts, izmantojot UTF-8 rakstzīmju kodējuma un URL kodējuma nosacījumus.

Abas iepriekšējo divu darbību vērtības ir jāapvieno ar atdalītāju kolu “:” starp tām.

Iegūtā vērtība ir jāpārvērš, izmantojot bāzes 64 kodējumu bez rindiņu pārtraukumiem.

Šim nolūkam var izmantot "MIME Tools" rīku "Notepad++".

API-Key = base64[url_encode(utf8(<client_id>)) ':' url_encode(utf8(<client_secret>))]

API autorizācijas izsaukumi

Lai veiktu API izsaukumus no autorizācijas servera, ir jāiegūst API piekļuves pilnvara, kas atbilst OAuth 2.0 pieprasījuma plūsmai un sastāv no divām darbībām:

1. API autorizācijas koda pieprasījums
2. API piekļuves marķiera pieprasījums

Ja autorizācijas koda iegūšanai ir nepieciešams saņemt galalietotāja apstiprinājumu, autorizācijas serveris novirza lietotāja pārlūkprogrammu uz identitātes sniedzēju, lai veiktu lietotāja autentifikāciju. Ja galalietotājs šajā brīdī nav autentificēts, pārlūkprogramma parāda galalietotājam pieteikšanās lapu ar iespējamām pieteikšanās metodēm (viedkartes, eParaksts mobile vai eID Scan) vai, ja pakalpojuma sniedzējs veic novirzīšanu uz konkrētu pieteikšanās metodi (viedkartes, eParaksts mobile vai eID Scan), galalietotājs tiek novirzīts uz konkrētu pieteikšanās procesu. Ja lietotājs jau ir autentificēts un identitātes nodrošinātājs atbalsta vienoto pieteikšanos (SSO), pieteikšanās lapa vairs netiek parādīta un darbība tiek apstiprināta automātiski. Autorizācijas serveris izsniedz Bearer tipa OAuth 2.0 piekļuves marķierus, un tā piekļuves tiesības tiek nodrošinātas ar autorizācijas koda pieprasījumu ar noteiktu tvērumu (scope). Lai veiktu API izsaukumus ar šo autorizācijas metodi saskaņā ar OAuth 2.0 specifikāciju, piekļuves marķiera API izsaukumi ir jāpievieno kā HTTP pieprasījuma galvenes autorizācijas atribūts.

Authorization: Bearer <token>

Lai kontrolētu Pakalpojuma sniedzēja lietojumprogrammas piekļuvi pieprasītajam pakalpojumam, piekļuves marķieri tiek validēti katrā API izsaukumā. Katra validācija ietver marķiera derīguma termiņu, domēna identitāti un saistīto tvērumu. Lai izvairītos no situācijas, kad marķiera derīguma termiņš ir beidzies, pirms katra API izsaukuma ieteicams pieprasīt jaunu marķieri.