🥇IdentityServer4. Основни понятия. OpenID Connect, OAuth 2.0 и JWT

С този пост искам да открия серия статии, посветени на IdentityServer4. Започваме с основните понятия.

Най-перспективният в момента протокол за удостоверяване е OpenID Connect, а протоколът за авторизация (предоставяне на достъп) е OAuth 2.0. IdentityServer4 реализира тези два протокола. Той е оптимизиран за решаване на типични проблеми по сигурността.

OpenID Connect — това е протокол и стандарт за удостоверяване, той не предоставя достъп до ресурси (Web API), но тъй като е разработен върху протокол за авторизация OAuth 2.0, той позволява получаването на параметри на профила на потребителя, сякаш сте получили достъп до ресурса UserInfo.
JWT (JSON Web Token) представлява уеб стандарт, който определя начин за предаване на данни за потребителя в JSON формат в задължен вид.
OAuth 2.0 (RFC 6749) — това е протокол и стандарт за авторизация. Той позволява на приложенията да получат достъп до защитени ресурси, например Web API.

Нека погледнем диаграмата за достъп до защитен ресурс и да разгледаме основните стъпки и приетата терминология:

Клиентът иска от потребителя разрешение да премине авторизация от негово име. Клиент — това е клиентско приложение, което се обраща към защитените ресурси от името на собственика на ресурсите. Ресурс — това са всички наши защитени услуги. Web API.
Потребителят позволява на клиентското приложение да премине авторизация от негово име, например, въвеждайки потребителско име и парола. Потребителското име и паролата ще бъдат основа за авторизация на клиентското приложение. Потребител (собственик на ресурса) — програма или човек, който може да предостави достъп до защитени ресурси, например, чрез въвеждане на потребителско име (username) и парола (password);
Клиентското приложение иска токен за достъп от IdentityServer4 чрез предоставяне на информация за самото себе си (client_id, client_secret), предоставяне на разрешение за авторизация от потребителя (username, парола) и предоставяне на grant_type и scope. След това сървърът за авторизация проверява автентичността на клиента и данните на собственика на ресурса (потребителско име и парола).
Протоколът OAuth 2.0 извършва удостоверяване не само на потребителя, но и на клиентското приложение, което осъществява достъп до ресурсите. За тази цел протоколът предвижда такива параметри като client_id и client_secret.
client_id — това е идентификатор на клиентското приложение, използван IdentityServer4 за търсене на информация за клиента.
client_secret являва аналог на паролата за клиентското приложение и се използва за удостоверяване на клиентското приложение на IdentityServer4. Тайната на клиента трябва да бъде известна само на приложението и API. На основата на казаното по-горе можем да заключим, че IdentityServer4 трябва да знае за своите клиенти.
Ако автентичността на приложението е потвърдена и разрешението за авторизация е валидно, IdentiryServer4 създава access-токен (токен за достъп) за приложението и не задължителен ключ за обновление (refresh-токен). Процесът на авторизация е завършен. Ако искането е невалидно или несанкционирано, авторизационният сървър връща код с съответното съобщение за грешка.
Клиентското приложение отправя искане за данни към защитен Web API, предоставяйки токена за достъп за авторизация. Ако кодът на отговора от сървъра на ресурсите 401, 403 или 498, то токенът за достъп, използван за удостоверяване, е невалиден или изтекъл.
Ако токенът е валиден, Web API предоставя данни на приложението.

Типове токени

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

identity-токен (токен за идентификация) — резултат от процеса на удостоверяване. Съдържа идентификатор на потребителя и информация как и кога потребителят минава през удостоверяване. Може да бъде разширен със свои данни.
access-токен (токен за достъп) — предава се на защитения API и се използва от него за авторизация (разрешаване на достъп) до своите данни.
refresh-токен (токен за обновление) — не задължителен параметър, който авторизационният сървър може да върне в отговор на искане за токен за достъп.

Въведем още две понятия:

Authenticatation Server Url — крайна точка за получаване на ключа за достъп. Всички искания за предоставяне и подновяване на ключовете за достъп ще бъдат насочвани към този URL адрес.

Resource Url — URL адрес на защитения ресурс, към който трябва да се обърнете, за да получите достъп до него, предоставяйки му ключа за достъп в заглавката за авторизация.

Искане за ключ за достъп

За искане на ключ за достъп клиентът прави 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, парола, client_id и client_secret бяха разгледани по-горе. Да разгледаме останалите параметри:

grant_type — тип награда или тип разрешение за авторизация. Тип разрешение за авторизация зависи от метода на заявка за авторизация, използван от приложението, а също и от това какви типове разрешение се поддържат от API. В нашия случай той ще има стойност парола, което според спецификацията OAuth 2.0 отговаря на наградата за данни за достъп на собственика на ресурса (авторизация с потребителско име и парола).

Протокол OAuth 2.0 определя следните типове награди, изискващи задължително взаимодействие с потребителите:

код за авторизация (authorization code). Той е един от най-разпространените типове разрешение за авторизация, тъй като е много подходящ за сървърни приложения (server-side applications), където изходният код на приложението и секретът на клиента не са достъпни за външни лица;
имплицитен (implicit). Имплицитният тип разрешение за авторизация се използва от мобилни и уеб-приложения, където конфиденциалността на секретите на клиента не може да бъде гарантирана;

И типовете награди, които могат да се извършват без интерактивно взаимодействие с потребителите:

данни на собственика на ресурса (resource owner). Този тип разрешение следва да се използва само когато клиентското приложение е в доверени отношения с потребителя и потребителят е спокоен относно въвеждането на своето потребителско име и парола. Този тип разрешение трябва да се използва само когато други опции не са налични. Този тип разрешение е удобен за корпоративни клиенти, които вече са използвали данните на потребителите в своята система и искат да преминат към OAuth 2.0.
данни на клиента. Използват се при достъп на приложението до API. Това може да бъде полезно, например, когато приложението иска да обнови собствената си регистрационна информация в услугата или URI за пренасочване, или да получава достъп до друга информация, съхранявана в акаунта на приложението в услугата, чрез API на услугата.

scope — това е незадължителен параметър. Той определя обхвата на видимост. Токенът за достъп, върнат от сървъра, ще осигури достъп само до тези услуги, които попада в този обхват. Т.е. можем да обединим няколко услуги под един обхват и ако клиентът получи ключ за достъп до този обхват, той получава достъп до всички тези услуги. Също така, обхватът може да се използва за ограничаване на правата за удостоверяване (например, достъп за четене или писане)

Източник: habr.com