Spotnana autentifikācijas plūsmas — pārskats

Izveidoja Ashish Chaudhary, Pārveidots Svētd, 5 Okt pie 5:27 AM pēc Ashish Chaudhary

Spotnana autentifikācijas plūsmas — pārskats

SATURA RĀDĪTĀJS

Spotnana autentifikācijas plūsmas — pārskats
- Galvenās sastāvdaļas
- Atbalstītās autentifikācijas metodes

Spotnana piedāvā vairākas autentifikācijas metodes, kas partneriem ļauj droši integrēt savas sistēmas ar mūsu platformu. Šajā dokumentācijā ir apkopots pārskats par visām Spotnana atbalstītajām autentifikācijas iespējām, kā arī detalizēti izskaidrots, kā katra no tām darbojas. Šeit aprakstītās autentifikācijas plūsmas parāda, kā Spotnana pārbauda un piešķir piekļuvi lietotājiem organizācijas līmeņa resursiem (t.i., resursiem, kas pieder lietotāja uzņēmumam Spotnana platformā).

Galvenās sastāvdaļas

Pirms sākat darbu, iepazīstieties ar šo būtisko sistēmas komponentu skaidrojumu, kas tiks lietoti šajā dokumentācijā.

Spotnana lietotāja saskarne(Spotnana User Interface) Tas ir Spotnana tīmekļa lietotnes priekšgals (jeb tiešsaistes rezervēšanas rīks) vai Spotnana mobilā lietotne. Šeit īpaši domāta pieteikšanās lapa, kas uzsāk autentifikācijas procesu, kad lietotājs pieslēdzas vai izveido jaunu kontu.
Spotnana serveris Spotnana aizmugursistēmas serveris, kas tiek izmantots autentifikācijai (piemēram, lai piešķirtu lietotājam piekļuvi resursiem un droši glabātu apstrādātu lietotāju informāciju).
Partnera lietotāja saskarne (Partner's User Interface) Tā ir partneru izmantotā lietotāja saskarne (priekšgala lietotne), lai piekļūtu Spotnana platformai. Piemēram, iFrame autentifikācijas gadījumā Spotnana platforma tiek iekļauta partnera lietotāja saskarnē, un lietotāji Spotnana izmanto caur partnera vidi.
Partnera serveris Viens vai vairāki partneru aizmugursistēmas serveri, kas tiek izmantoti Spotnana integrācijai.
Spotnana IdP (Spotnana Identity Provider) Spotnana iekšējais pakalpojums, kas nodrošina lietotāju identitātes pārvaldību un autorizāciju.
Partnera IdP Partneru izmantotie trešo pušu identitātes nodrošinātāji (IdP). Biežākie piemēri ir Google un Azure.
OBT Spotnana tiešsaistes rezervēšanas rīks (Online Booking Tool — OBT), kas pieejams šeit: https://app.spotnana.com/
Subjekta marķieris iFrame (vai marķieru apmaiņas) autentifikācijas gadījumā subjekta marķieris apzīmē lietotāja identitāti. Šis marķieris tiek izmantots, lai izgūtu informāciju par lietotāju un piešķirtu viņam piekļuvi Spotnana platformai.
Piekļuves marķieris Akreditācijas dati (OAuth), ko partneru lietotnes izmanto, lai piekļūtu aizsargātiem resursiem lietotāja vārdā. Tas ir īslaicīgs autorizācijas atslēga, kas ļauj lietotnēm veikt API pieprasījumus, neatklājot lietotāja paroles.
Atjaunošanas marķieris Ilgtermiņa akreditācijas dati, kas ļauj iegūt jaunus piekļuves marķierus, neliekot lietotājam atkārtoti autentificēties. Parasti tas tiek izsniegts kopā ar piekļuves marķieri pirmajā pieslēgšanās reizē.
Klienta akreditācijas dati Informācija, kas tiek piešķirta lietotājiem, kuri tieši izmanto Spotnana API (t.i., unikāls clientId un clientSecret).
PID (personas identifikators) Lietotājam izveidots personas identifikators. PID tiek izmantots, lai iegūtu lietotāja informāciju no Spotnana servera.
orgId Unikāls identifikators, ko Spotnana piešķir lietotāja organizācijai.
tmcId Unikāls identifikators, ko Spotnana piešķir TMC (ceļojumu pārvaldības uzņēmumam).

Atbalstītās autentifikācijas metodes

Tālāk ir uzskaitītas dažādas autentifikācijas metodes, ko Spotnana atbalsta:

Autentifikācija ar paroli
- Eksistējošs lietotājs
- Jauns lietotājs
Autentifikācija ar IdP
Autentifikācija caur API
Autentifikācija, izmantojot iFrame
Autentifikācija ar autorizācijas kodu
Mašīna–mašīna (M2M) autentifikācija

Autentifikācija ar paroli

Lietojot autentifikāciju ar paroli, Spotnana lietotāja saskarne (piemēram, pieteikšanās vai reģistrācijas lapa OBT) uzsāk un vada autentifikācijas procesu ar Spotnana serveriem. Šai metodei ir divas dažādas plūsmas — atkarībā no tā, vai lietotājs pieslēdzas ar jau esošu profilu vai reģistrē jaunu. Abas šīs autentifikācijas plūsmas tālāk skaidrotas ar secības diagrammām.

Eksistējošs lietotājs

Zemāk redzamā secības diagramma un soļi paskaidro, kā Spotnana lietotāja saskarne sadarbojas ar aizmugursistēmas pakalpojumiem, lai autentificētu jau esošu lietotāju.

Attēls: Secības diagramma, kas izskaidro autentifikāciju ar paroli esošiem lietotājiem.

1. solis	Plūsma
Esošs lietotājs pieslēdzas OBT vai Spotnana mobilajā lietotnē, izmantojot savu e-pastu.
1	Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana serverim, lai saņemtu lietotāja autentifikācijas konfigurācijas informāciju. Pieprasījumā kā parametri tiek norādīti lietotāja pieteikšanās dati. Atbildē tiek atgriezts lietotāja `tmcId`, `orgId`, kā arī `authProviderType`.
2	Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana IdP, izmantojot `clientId`, e-pastu un paroli. Spotnana IdP ģenerē jaunu bearer token un nosūta to Spotnana lietotāja saskarnei. Šajā solī lietotājs tiek autentificēts.
3	Pēc tam, kad lietotājs ir autentificēts 2. solī, visos nākamajos API pieprasījumos jāiekļauj bearer token, `orgId`un `tmcId` pieprasījuma galvenē. Visos ienākošajos API pieprasījumos tiek pārbaudīts bearer token, un atbilde tiek nosūtīta atpakaļ Spotnana lietotāja saskarnei.

Jauns lietotājs

Zemāk redzamā secības diagramma un soļi paskaidro, kā Spotnana lietotāja saskarne sadarbojas ar aizmugursistēmas pakalpojumiem, lai autentificētu jaunu lietotāju (vai esošu lietotāju, kurš vēlas atiestatīt paroli).

Attēls: Secības diagramma, kas izskaidro autentifikāciju ar paroli jauniem lietotājiem.

1. solis	Plūsma
Jauns lietotājs ievada savu e-pastu Spotnana OBT pieteikšanās lapā un nospiež Tālāk.
1	Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana serverim, lai saņemtu lietotāja autentifikācijas konfigurācijas informāciju. Pieprasījumā kā parametri tiek norādīti lietotāja pieteikšanās dati. Atbildē tiek atgriezts lietotāja `tmcId`, `orgId`, kā arī `authProviderType`.
1.a solis	Lietotājs ievada jaunu paroli un nospiež Tālāk.
2	Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana IdP, lai reģistrētu lietotāju, norādot `clientId`, e-pastu un jauno paroli. Pēc datu reģistrācijas uz lietotāja e-pastu tiek nosūtīts vienreizējs paroles kods (OTP).
3	Lietotājs ievada OTP Spotnana lietotāja saskarnē un nospiež Apstiprināt. Spotnana lietotāja saskarne nosūta pieprasījumu Spotnana IdP, lai pārbaudītu OTP un ģenerētu bearer token pieslēgšanās veikšanai. Bearer token tiek ģenerēts un nosūtīts Spotnana lietotāja saskarnei. Tas nozīmē, ka lietotājs ir veiksmīgi autentificēts un var piekļūt Spotnana platformai, izmantojot šo tokenu.
4	Pēc tam, kad lietotājs ir autentificēts 3. solī, visos nākamajos API pieprasījumos jāiekļauj bearer token, `orgId`un `tmcId` pieprasījuma galvenē. Visos ienākošajos API pieprasījumos tiek pārbaudīts bearer token, un atbilde tiek nosūtīta atpakaļ Spotnana lietotāja saskarnei.

Autentifikācija ar IdP

Spotnana atbalsta autentifikāciju ar tādiem IdP kā Google, Azure, pielāgotus IdP ar OpenID Connect, kā arī SAML protokolu. Zemāk redzamā secības diagramma un soļi izskaidro autentifikācijas plūsmu ar IdP.

Attēls: Secības diagramma, kas izskaidro autentifikāciju ar IdP.

1. solis	Plūsma
Lietotājs pieslēdzas OBT vai Spotnana mobilajā lietotnē, izmantojot savu e-pasta adresi.
1	Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana serverim, lai saņemtu lietotāja autentifikācijas konfigurācijas informāciju. Pieprasījumā kā parametri tiek norādīti lietotāja pieteikšanās dati. Atbildē tiek atgriezts lietotāja `tmcId`, `orgId`, kā arī `authProviderType`.
2	Spotnana lietotāja saskarne pāradresē pieprasījumu uz Spotnana IdP.
3	Spotnana IdP pāradresē pieprasījumu uz partnera IdP, tādējādi uzsākot lietotāja autentifikāciju caur IdP. Piezīme: Katrai pāradresācijai tiek atgriezts 302 statusa kods, kas norāda, ka pieprasījums ir novirzīts uz citu URL.
4	Starp Spotnana IdP un partnera IdP tiek izveidots savienojums, lai pārliecinātos, ka lietotāju autentificē partnera IdP. Piezīme: Šī savienojuma laikā Spotnana IdP nosūta `clientId` un `clientSecret` kā URL kodētus datus API pieprasījumā partnera IdP. Ja IdP serveri nevar apstrādāt šo datu formātu, Spotnana serveris var darboties kā starpnieks un pārveidot datus partnerim saprotamā formā.
5	Partnera IdP veiksmīgi autentificē lietotāju. Piezīme: Pēc šī soļa lietotāja profils vēl jāapstiprina ar bearer token pārbaudi.
5.a solis	Pēc veiksmīgas autentifikācijas partnera IdP atbilde tiek nosūtīta Spotnana IdP.
5.b solis	Spotnana IdP ģenerē unikālu kodu lietotāja profilam un nosūta to Spotnana lietotāja saskarnei.
6	Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana IdP, izmantojot `clientID` un kodu, kas saņemts 5.(b) solī. Spotnana IdP ģenerē jaunu bearer token un nosūta to Spotnana lietotāja saskarnei. Piezīme: Bearer token veiksmīga izveide nozīmē, ka lietotājs ir autentificēts un var piekļūt Spotnana.
7	Pēc tam, kad lietotājs ir autentificēts 6. solī, visos nākamajos API pieprasījumos jāiekļauj bearer token, `orgId`un `tmcId` pieprasījuma galvenē. Visos ienākošajos API pieprasījumos tiek pārbaudīts bearer token, un atbilde tiek nosūtīta atpakaļ Spotnana lietotāja saskarnei.

Autentifikācija caur API

Partneri, kas izmanto Spotnana API, lai savienotos ar Spotnana platformu, var izmantot mūsu autentifikācijas galapunktu, lai ģenerētu bearer token saviem lietotājiem. Zemāk redzamā secības diagramma attēlo autentifikācijas plūsmu partneriem, kuri izmanto API autentifikāciju.

Attēls: Secības diagramma, kas izskaidro autentifikāciju caur API.

1. solis Plūsma

API lietotājs veic

1. solis	Plūsma
API lietotājs veic	POST pieprasījumu uz get-auth-token(clientId,clientSecret) `API galapunktu Spotnana serverī, lai ģenerētu un saņemtu pagaidu bearer token.` Lūk, piemērs cUrl pieprasījumam, ko var izmantot, zvanot uz get-auth-token `galapunktu:` curl -i -X POST \ https://api.spotnana.com/get-auth-token \ -H 'Content-Type: application/json' \ -d '{ "clientId": "sample-apiuser@tmcorg.com", "clientSecret": "<password>" }' Piezīme: Aizvietojiet clientId `un` clientSecret `vērtības ar jums piešķirtajiem Spotnana akreditācijas datiem.` 2
Spotnana serveris izsauc	getToken(clientId,clientSecret) `metodi Spotnana IdP, kas ģenerē pagaidu` bearerToken `un nosūta to atpakaļ Spotnana serverim.` Spotnana serveris šo bearer token nosūta API lietotājam kā JSON atbildi. Pēc tam, kad API lietotājs ir saņēmis bearer token, visos turpmākajos Spotnana API (piemēram,

POST pieprasījumu uz get-auth-token(clientId,clientSecret) API galapunktu Spotnana serverī, lai ģenerētu un saņemtu pagaidu bearer token. Lūk, piemērs cUrl pieprasījumam, ko var izmantot, zvanot uz

get-auth-token galapunktu: curl -i -X POST \ https://api.spotnana.com/get-auth-token \ -H 'Content-Type: application/json' \ -d '{ "clientId": "sample-apiuser@tmcorg.com", "clientSecret": "<password>" }'

Piezīme:

Aizvietojiet clientId un clientSecret vērtības ar jums piešķirtajiem Spotnana akreditācijas datiem. 2

Spotnana serveris izsauc

getToken(clientId,clientSecret) metodi Spotnana IdP, kas ģenerē pagaidu bearerToken un nosūta to atpakaļ Spotnana serverim. Spotnana serveris šo bearer token nosūta API lietotājam kā JSON atbildi.
Pēc tam, kad API lietotājs ir saņēmis bearer token, visos turpmākajos Spotnana API (piemēram,

Trip APIs ) pieprasījumos jāiekļauj bearer token galvenē autorizācijai.Piezīme:

Galapunktam get-auth-token(clientId, clientSecret) ir noteikts limits — 100 API pieprasījumi 5 minūtēs. Autentifikācija, izmantojot iFrame

iFrame jeb iebūvētais risinājums nozīmē, ka partneri Spotnana lietotāja saskarni ievieto savā lietotāja saskarnē, līdz ar to lietotāji Spotnana izmanto caur partnera vidi. Šajā scenārijā lietotāja autentifikācija notiek, apmainoties marķieriem starp partnera un Spotnana sistēmām.

Piezīme

: iFrame autentifikācijas gadījumā lietotājs, kas pieslēdzas, tiek dēvēts parcaller . Tas ļauj atbalstīt gadījumus, kad API vai mašīnas lietotājs pieslēdzas un pieprasa piekļuves marķieri citam lietotājam. Šāds API/mašīnas lietotājs var izmantot TMC (ceļojumu pārvaldības uzņēmuma) administratora akreditācijas datus, lai tieši savienotos ar Spotnana serveri. Tāpēc šeit lietosim terminucaller kā vispārīgu apzīmējumu — tas var būt gan lietotājs, kas pieslēdzas savam profilam, gan API/mašīnas lietotājs, kas pieprasa piekļuves marķieri citam lietotājam. Zemāk redzamā secības diagramma parāda, kā autentifikācijas plūsma tiek nodrošināta, apmainoties marķieriem starp Spotnana un partnera serveriem.

Attēls:

Secības diagramma, kas izskaidro autentifikāciju ar iFrame, izmantojot marķieru apmaiņu. 1. solis

Plūsma	Caller pieslēdzas, izmantojot partnera lietotāja saskarni.
1
Partnera lietotāja saskarne ielādē Spotnana lietotāja saskarni caur iFrame.	2
Spotnana lietotāja saskarne nosūta pieprasījumu partnera lietotāja saskarnei ar post message, lai saņemtu marķierus. Pieprasījumā tiek norādīts	type=TOKEN_EXCHANGE_REQUEST `.`3
Partnera lietotāja saskarne nosūta API pieprasījumu partnera serverim, lai iegūtu OAuth marķieri, tādējādi uzsākot nākamos autentifikācijas soļus.	3.a solis
Partnera serveris izsauc Spotnana serveri, izmantojot lietotāja akreditācijas datus un subjekta marķieri kā parametrus. Spotnana serveris pārbauda, vai pieprasījumu sūta API/mašīnas lietotājs.	3.b solis
Spotnana serveris izsauc partnera serveri, lai saņemtu subjekta (caller) e-pastu.	E-pasts tiek iegūts un nosūtīts Spotnana serverim, kas to izmanto lietotāja identifikācijai. 3.c solis
Atbildē uz API pieprasījumu no 1. soļa Spotnana serveris nosūta partnera serverim piekļuves un atjaunošanas marķieri.	Šī informācija tālāk tiek nodota partnera lietotāja saskarnei. 4
Partnera lietotāja saskarne nosūta marķieri Spotnana lietotāja saskarnei ar post message, norādot	type=TOKEN_EXCHANGE_RESPONSE. `5`
Spotnana lietotāja saskarne nosūta API pieprasījumu Spotnana serverim, lai ģenerētu un saņemtu jaunu bearer token.	Spotnana serveris ģenerē bearer token un nosūta to Spotnana lietotāja saskarnei. Piezīme: Bearer token veiksmīga izveide nozīmē, ka lietotājs ir autentificēts un var piekļūt Spotnana. 6
Pēc tam, kad lietotājs ir autentificēts 3. solī, visos nākamajos API pieprasījumos jāiekļauj bearer token,	orgId `un`tmcId `pieprasījuma galvenē.` Visos ienākošajos API pieprasījumos tiek pārbaudīts bearer token, un atbilde tiek nosūtīta atpakaļ Spotnana lietotāja saskarnei. Autentifikācija ar autorizācijas kodu

Zemāk redzamā secības diagramma parāda, kā autentifikācijas plūsma tiek nodrošināta, izmantojot autorizācijas kodu.

Attēls:

Secības diagramma, kas izskaidro autentifikāciju ar autorizācijas kodu. 1. solis

Plūsma	Partnera lietotāja saskarne izsauc partnera serveri, lai iegūtu autorizācijas kodu caller pieslēgšanās gadījumam. Autorizācijas kods tiek saņemts un nosūtīts atpakaļ partnera lietotāja saskarnei.
2	Partnera lietotāja saskarne nosūta pieprasījumu Spotnana lietotāja saskarnei, izmantojot pielāgotu pāradresācijas URL, kurā parametru veidā norādīts
tmcId	un `authCode` . `3` Spotnana lietotāja saskarne veic
POST	API pieprasījumu Spotnana serverim, izmantojot v2/auth/token/companies/<tmcId>(authCode) API galapunktu. `3.a solis` Spotnana serveris nosūta pieprasījumu partnera serverim, lai iegūtu lietotāja
pid	izmantojot autorizācijas kodu. `Lietotāja` pid tiek iegūts un nosūtīts Spotnana serverim. `3.b solis` Spotnana serveris ģenerē piekļuves un atjaunošanas marķieri un nosūta tos Spotnana lietotāja saskarnei.
4	Spotnana lietotāja saskarne nosūta pieprasījumu Spotnana serverim, izmantojot piekļuves un atjaunošanas marķieri, lai ģenerētu un saņemtu bearer token piekļuvei.
Bearer token tiek ģenerēts un nosūtīts Spotnana lietotāja saskarnei.	Piezīme: Bearer token veiksmīga izveide nozīmē, ka lietotājs ir autentificēts un var piekļūt Spotnana. 5 Pēc tam, kad lietotājs ir autentificēts 4. solī, visos nākamajos API pieprasījumos jāiekļauj bearer token,
orgId	un `tmcId`pieprasījuma galvenē. `Visos ienākošajos API pieprasījumos tiek pārbaudīts bearer token, un atbilde tiek nosūtīta atpakaļ Spotnana lietotāja saskarnei.` Piezīme: Šo autentifikācijas plūsmu nevar izmantot, ja TMC administrators atļauj vairākiem lietotājiem pieslēgties ar vienu un to pašu e-pastu.

Mašīna–mašīna (M2M) autentifikācija M2M autentifikācijas metode ir piemērota gadījumos, kad klienta lietotne izmanto trešās puses atgriezenisko URL, lai ģenerētu

accessToken

lietotājam. Zemāk redzamā secības diagramma attēlo M2M autentifikācijas plūsmu. Attēls: Secības diagramma, kas izskaidro M2M autentifikācijas plūsmu.

1. solis Plūsma

Visu lietotņu publiskās atslēgas, kas tiek izmantotas autentifikācijā, tiek sinhronizētas starp Spotnana serveri un Spotnana IdP. Tās vēlāk tiek izmantotas, lai pārbaudītu piekļuves marķieri autentifikācijas procesā.	1
Partnera serveris nosūta API pieprasījumu uz
/oauth2/token(clientId,clientSecret)	Spotnana IdP, lai ģenerētu bearer token. Jaunais bearer token tiek nosūtīts atpakaļ partnera serverim. `2` Partnera serveris nosūta API pieprasījumu uz trešās puses atgriezenisko URL, lai ģenerētu piekļuves marķieri lietotājam.
Šis piekļuves marķieris tiek izveidots un nosūtīts Spotnana serverim.	3 Spotnana serveris pārbauda piekļuves marķiera parakstu, izmantojot iepriekš sinhronizētās publiskās atslēgas. Tāpat tiek pārbaudīts
claim_id	kas apliecina partnera identitāti. `Piekļuves marķieris tālāk tiek nosūtīts partnera serverim lietotāja autentifikācijai.` ... ...