🥇ИдентитиСервер4. Основни појмови. ОпенИД Цоннецт, ОАутх 2.0 и ЈВТ

Овим постом желим да отворим нит чланака посвећених ИдентитиСервер4. Почнимо са основним концептима.

Протокол за аутентификацију који највише обећава у овом тренутку је ОпенИД Цоннецт, а протокол ауторизације (обезбеђивање приступа) је ОАутх 2.0. ИдентитиСервер4 имплементира ова два протокола. Оптимизован је за решавање типични проблеми сигурност.

ОпенИД Цоннецт је протокол и стандард за аутентификацију, не пружа приступ ресурсима (Веб АПИ), али пошто дизајниран је на врху протокола за ауторизацију ОАутх 2.0, омогућава вам да добијете параметре корисничког профила као да имате приступ ресурсу Подаци о кориснику.
ЈВТ (ЈСОН Веб Токен) је веб стандард који дефинише начин за пренос корисничких података у ЈСОН формату у шифрованом облику.
ОАутх 2.0 (РФЦ 6749) је ауторизациони протокол и стандард. Омогућава апликацијама да приступе заштићеним ресурсима, као што су веб АПИ-ји.

Хајде да погледамо дијаграм приступа заштићеном ресурсу и разумемо главне кораке и прихваћену терминологију:

Клијент тражи дозволу од корисника да се аутентификује у његово име. Цустомер је клијентска апликација која приступа заштићеним ресурсима у име власника ресурса. ресурс - то су све наше заштићене услуге Веб АПИ.
Корисник дозвољава клијентској апликацији да се аутентификује у његово име, на пример, уношењем корисничког имена и лозинке. Пријава и лозинка ће бити одобрење за клијентску апликацију. Корисник (власник ресурса) — програм или особа која може да одобри приступ заштићеним ресурсима, на пример, уношењем корисничког имена (корисничког имена) и лозинке (лозинке);
Клијентска апликација захтева приступни токен од IdentityServer4 пружањем информација о себи (client_id, client_secret), додељивање дозволе за ауторизацију од корисника (username, password) и обезбеђивање grant_type и scope. Затим ауторизациони сервер проверава аутентичност клијента и детаље о власнику ресурса (логин и лозинка).
ОАутх 2.0 протокол потврђује аутентичност не само корисника, већ и клијентске апликације која приступа ресурсима. У ту сврху, протокол обезбеђује такве параметре као ИД клијента и цлиент_сецрет.
ИД клијента је идентификатор клијентске апликације који се користи IdentityServer4 за тражење информација о клијенту.
цлиент_сецрет је аналогна лозинки за клијентску апликацију и користи се за аутентификацију клијентске апликације на IdentityServer4. Тајна клијента треба да буде позната само апликацији и АПИ-ју. На основу наведеног закључујемо да ИдентитиСервер4 треба да зна о својим клијентима.
Ако је апликација потврђена и дозвола за ауторизацију је важећа, IdentiryServer4 ствара access-токен (токен за приступ) за апликацију и опциони кључ за освежавање (refresh-токен). Процес ауторизације је завршен. Ако је захтев неважећи или неовлашћен, сервер за ауторизацију враћа код са одговарајућом поруком о грешци.
Клијентска апликација приступа безбедном веб АПИ-ју за податке, обезбеђујући приступни токен за ауторизацију. Ако код одговора сервера ресурса 401, 403 или 498, онда је токен за приступ који се користи за аутентификацију неважећи или истекао.
Ако је токен валидан, Web API даје податке апликацији.

Врсте токена

Регистрован у IdentityServer4 клијентима је дозвољено да траже IdentityServer4 identity- жетон, access-жетон и refresh-токен.

токен идентитета (идентификациони токен) — резултат процеса аутентификације. Садржи кориснички ИД и информације о томе како и када је корисник аутентификован. Можете га проширити сопственим подацима.
приступни токен — се преноси заштићеном АПИ-ју и користи га да овласти (дозволи приступ) својим подацима.
рефресх-токен (токен за освежавање) је опциони параметар који сервер за ауторизацију може да врати као одговор на захтев токена за приступ.

Хајде да представимо још два концепта:

Урл сервера за аутентификацију — крајња тачка за добијање приступног кључа. Све захтеве за обезбеђивање и обнављање приступних кључева ћемо усмерити на ову УРЛ адресу.

Урл ресурса — УРЛ заштићеног ресурса који се мора контактирати да бисте му приступили, прослеђујући му приступни кључ у заглављу ауторизације.

Захтев за приступни кључ

Да би затражио приступни кључ, клијент то чини POST захтев до крајње тачке IdentityServer4 са следећим насловом

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

и прослеђивање следећих параметара:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id и client_secret о којима је било речи горе. Погледајмо преостале параметре:

грант_типе — тип одобрења или тип овлашћења. Тип дозволе за ауторизацију зависи од методе захтева за ауторизацију коју користи апликација, као и од тога које типове дозвола подржава АПИ. У нашем случају то ће бити важно password, што је према спецификацији OAuth 2.0 одговара детаљима о додели приступа власника ресурса (овлашћење путем логин-а и лозинке).

Протокол OAuth 2.0 дефинише следеће врсте дотација које захтевају обавезна интеракција са корисницима:

код за дозволу. То је једна од најчешћих врста дозволе за ауторизацију, јер погодан за апликације на страни сервера, где изворни код апликације и тајна клијента нису доступни аутсајдерима;
имплицитно. Тип дозволе имплицитне ауторизације користе мобилне и веб апликације где се не може гарантовати поверљивост тајне клијента;

И врсте грантова које може се извршити без интеракције корисника:

подаци о власнику ресурса. Ова врста дозволе треба да се користи само ако корисник има поверења у клијентску апликацију и ако је корисник спреман да унесе своју пријаву и лозинку. Овај тип дозволе треба користити само када друге опције нису доступне. Ова врста дозволе је погодна за корпоративне клијенте који су већ користили корисничке акредитиве у свом систему и желе да пређу на OAuth 2.0.
акредитиве клијента. Користи се када апликација приступа АПИ-ју. Ово може бити корисно, на пример, када апликација жели да ажурира сопствене информације о регистрацији услуге или преусмери УРИ, или да приступи другим информацијама ускладиштеним на налогу услуге апликације преко АПИ-ја услуге.

обим - Ово је опциони параметар. Дефинише обим. Приступни токен који врати сервер ће обезбедити приступ само услугама које спадају у тај опсег. Оне. можемо комбиновати неколико услуга под једним опсегом и ако клијент добије приступни кључ за овај опсег, добија приступ свим овим услугама. Опсег се такође може користити за ограничавање права ауторизације (на пример, приступ за читање или писање)

Извор: ввв.хабр.цом