Запис на архитектурно решение: варианти за автентикация и авторизация

Автентикацията и авторизацията в уеб приложенията са две основни понятия при защитата на достъпа до приложения и услуги. И двете се отнасят до самоличността на потребителите и до начина, по който се предоставят разрешения, но се фокусират върху различни аспекти:

Автентикацията е процесът на проверка на самоличността на потребител или система.
Авторизацията е процесът на определяне до какви ресурси или действия има достъп автентикираният потребител или система.

Сега нека се задълбочим в конкретните протоколи и технологии, които споменахте и които обикновено се използват в съвременните уеб приложения за управление на автентикацията и авторизацията.

1. OAuth (Open Authorization)

OAuth е отворен стандарт за авторизация. Той позволява на потребител да предостави на приложение на трета страна ограничен достъп до своите ресурси, без да споделя своите идентификационни данни. Основната идея е делегиран достъп. OAuth често се използва в ситуации, в които потребителите могат да влязат в услуга на трета страна (напр. влизане с Google), без да предоставят директно потребителското си име и парола на третата страна.

Поток: OAuth обикновено следва базиран на токени поток, при който сървър за авторизация издава токен за достъп на приложението на третата страна. Този токен представлява разрешенията на потребителя и приложението го използва, за да достъпва данните или ресурсите на потребителя от API.
Пример: Потребител влиза в приложение на трета страна със своя акаунт в Google. Google проверява самоличността на потребителя и след това предоставя токен, който позволява на приложението на третата страна да достъпва някои данни на Google (напр. Google Calendar).

OAuth не обработва директно автентикацията; той е за предоставяне на достъп. За автентикация OAuth често се комбинира с други протоколи, като OpenID Connect.

2. OpenID Connect (OIDC)

OpenID Connect (OIDC) е слой за самоличност, изграден върху OAuth 2.0, който добавя автентикация към възможностите за авторизация на OAuth. По същество OpenID Connect разширява OAuth, за да обработва автентикация на потребители и предоставя стандартизиран начин приложенията да проверяват самоличността на потребител.

Поток: Когато потребител влиза чрез OpenID Connect, приложението на третата страна изисква ID токен (в допълнение към токена за достъп на OAuth). ID токенът съдържа информация за потребителя (като потребителско име, имейл и други твърдения). Това позволява на приложението да знае кой е потребителят и дали е автентикиран.
Пример: Влизането в услуга като Slack с вашия акаунт в Google (Google е доставчикът на OpenID Connect) включва автентикация чрез OpenID Connect, докато OAuth управлява достъпа до вашите ресурси в Google.

OIDC улеснява приложенията на трети страни да автентикират потребители, като същевременно позволява прецизен контрол върху това до какви ресурси тези приложения могат да имат достъп.

3. SAML (Security Assertion Markup Language)

SAML е по-стар, базиран на XML стандарт, използван за обмен на данни за автентикация и авторизация между страни, особено в сценарии за Single Sign-On (SSO). Използва се основно в корпоративни среди, за да могат потребителите да се автентикират веднъж и да получат достъп до множество приложения, без да въвеждат отново идентификационни данни.

Поток: Потребителят първо се автентикира при доставчик на самоличност (IdP). IdP генерира подписано SAML твърдение, което включва самоличността на потребителя и свързани атрибути. Твърдението се изпраща на доставчика на услугата (SP), който го използва, за да разреши достъп до приложението.
Пример: Служител влиза в корпоративния си портал (IdP) и автоматично е влязъл в други системи като имейл, CRM и т.н., без да въвежда отново идентификационни данни. Процесът на автентикация се основава на SAML твърдението, изпратено от IdP.

SAML обикновено се използва в корпоративни SSO решения и работи добре за уеб приложения в корпоративни среди, но е по-малко удобен за мобилни устройства в сравнение с OAuth/OIDC.

4. WS-Federation (Web Services Federation)

WS-Federation е друг протокол, използван за Single Sign-On (SSO), особено в корпоративни среди, базирани на Microsoft. Той е част от семейството спецификации WS- (Web Services)* и позволява федерация на самоличности между различни домейни за сигурност (например между различни организации или между различни услуги).

Поток: WS-Federation позволява на доверен доставчик на самоличност (IdP) да автентикира потребители и да издава токени, които доставчикът на услугата може да използва за авторизация. Подобен е на SAML, но често се използва в сценарии, които разчитат силно на технологии на Microsoft.
Пример: Потребител влиза в корпоративно приложение, хоствано в Microsoft Azure Active Directory (AD), и неговата самоличност може да се използва за достъп до други федерирани услуги, включително приложения, хоствани от доставчици трети страни.

Макар че WS-Federation до голяма степен е заменен от по-нови протоколи като OAuth2.0 и OpenID Connect в много съвременни уеб среди, той все още се използва в наследени системи, особено в предприятия, ориентирани към Microsoft.

5. LDAP (Lightweight Directory Access Protocol)

LDAP е протокол, използван за достъп и управление на директорийни услуги, обикновено използван за съхранение на идентификационни данни на потребители и управление на контрола на достъпа в централизирана директория (често наричана Directory Service). LDAP не е конкретно за автентикация или авторизация, но се използва за съхранение и извличане на данни за самоличност, които след това се използват в тези процеси.

Автентикация: LDAP позволява на приложение да автентикира потребители, като запитва директорийната услуга за идентификационни данни (като пароли).
Авторизация: Той управлява и потребителските роли и разрешения, като помага да се определи дали потребителят има достъп до определени ресурси.
Пример: Много предприятия използват директории, базирани на LDAP (напр. Active Directory), за автентикация и авторизация, особено в среди с Windows.

LDAP е от решаващо значение за предприятията при управлението на достъпа на потребителите в вътрешните системи, но в съвременния уеб контекст LDAP често се интегрира с други протоколи като SAML или OAuth за по-пълно управление на самоличността.

6. Социални SSO доставчици

Социалните доставчици на Single Sign-On (SSO) като Facebook, Google, Twitter, GitHub и други позволяват на потребителите да се автентикират в приложения на трети страни със своите идентификационни данни от социалните медии. Това е вид автентикация, базирана на OAuth, при която услугата на третата страна (напр. Google) е доставчикът на самоличност.

Поток: Потребителят натиска „Вход с Google“ (например). Приложението пренасочва към Google, където потребителят влиза (ако вече не е влязъл). След това Google предоставя токен за достъп или ID токен на приложението на третата страна, който може да се използва за автентикиране на потребителя и евентуално за достъп до неговите данни.
Пример: Много приложения ви позволяват да влезете със своите идентификационни данни от Google или Facebook. Приложението използва OAuth или OpenID Connect зад кулисите, за да провери самоличността ви и в някои случаи да получи достъп до определени данни от социалните медии.

Социалният SSO е удобен и широко приет метод за автентикация, защото намалява затрудненията за потребителите, които може да не искат да създават още едно потребителско име и парола.

Резюме на разликите:

OAuth: Използва се за авторизация, позволява на приложения на трети страни да достъпват потребителски данни, без да разкриват идентификационните данни.
OpenID Connect: Разширява OAuth, за да осигури автентикация, като позволява на приложенията да проверяват самоличността на потребителя.
SAML: Базиран на XML протокол, използван за SSO, често в корпоративни среди.
WS-Federation: Специфичен за Microsoft протокол за федерация на самоличности, използван в наследени системи.
LDAP: Протокол за запитване към директорийни услуги за автентикиране на потребители и управление на авторизацията.
Социални SSO доставчици: Системи, базирани на OAuth (като Google, Facebook), които позволяват на приложения на трети страни да автентикират потребители чрез техните идентификационни данни от социалните медии.

Всяка от тези технологии има свои силни страни и случаи на употреба и в съвременните приложения може да видите комбинация от тях, използвана за различни аспекти на сигурността (напр. OAuth/OIDC за достъп до API, SAML за корпоративен SSO).