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.

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

1. Клиентът иска разрешение от потребителя да премине през упълномощаване от негово име. Клиент — това е клиентско приложение, което се обръща към защитените ресурси от името на собственика на ресурсите. Ресурсът — това са всички наши защитени услуги Web API.

2. Потребителят позволява на клиентското приложение да премине през упълномощаване от негово име, например, въвежда потребителско име и парола. Потребителското име и парола ще бъдат упълномощителният грант за клиентското приложение. Потребител (собственик на ресурса) — програма или човек, който може да предостави достъп до защитени ресурси, например, чрез въвеждане на потребителско име (username) и парола (password);

3. Клиентското приложение иска токен за достъп от IdentityServer4 чрез предоставяне на информация за самото себе си (client_id, client_secret), предоставяне на разрешение за упълномощаване от потребителя (username, password) и предоставяне grant_type и scope. След това сървърът за упълномощаване проверява автентичността на клиента и данните на собственика на ресурса (потребителското име и парола).

   Протоколът OAuth 2.0 провежда удостоверяване не само на потребителя, но и на клиентското приложение, осъществяващо достъп до ресурсите. За тази цел протоколът предвижда такива параметри като client_id и client_secret.
   client_id — това е идентификатор на клиентското приложение, използвано IdentityServer4 за намиране на информация за клиента.
   client_secret е аналог на паролата за клиентското приложение и се използва за автентикация на клиентското приложение. IdentityServer4. Секретът на клиента трябва да бъде известен само на приложението и API-то.. Въз основа на горепосоченото можем да заключим, че IdentityServer4 трябва да знае за своите клиенти..

4. Ако автентичността на приложението е потвърдена и разрешението за авторизация е валидно, IdentiryServer4 създава access токен (токен за достъп) за приложението и незадължителен refresh токен (refresh токен). Процесът на авторизация е завършен. Ако заявката е недопустима или неразрешена, сървърът за авторизация връща код с подходящо съобщение за грешка.

5. Клиентското приложение се обръща за данни към защитен Web API, предоставяйки тъкмо токена за достъп за авторизация. Ако кодът на отговор на сървъра на ресурсите 401, 403 или 498, то токена за достъп, използван за удостоверяване, е невалиден или е изтекъл.

6. Ако токенът е валиден, Web API той предоставя данни на приложението.

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

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

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

Нека въведем още две понятия:

Authentication 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, password, client_id и client_secret бяха разгледани по-горе. Нека разгледаме останалите параметри:

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

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

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

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

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

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

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