Введение

Мы далеко не всегда хотим, чтобы наш бэкенд был доступен всем просто так. На самом деле, чаще всего мы хотим обратного. Сегодня я расскажу вам, что такое аутентификация и авторизация, какие виды аутентификации существуют и как они работают. Судя по количеству вопросов на эту тему, будет интересно :)

Терминология

Есть три штуки, которые очень часто путают:

  • идентификация: попросту говоря, ваш логин или что-то такое. То есть, таким способом вы заявляете, кто вы такой.
  • аутентификация: доказательство, что вы и вправду тот, кем себя идентифицировали: пароль, ключ, такие штуки
  • авторизация: проверка, что вы имеете доступ к тому ресурсу, что запрашиваете

Если проще, идентификация: получение вашего логина, аутентификация: подтверждение его паролем, авторизация: проверка, что вы можете в приложении делать то, что пытаетесь.

Но все чуточку сложнее, чем кажется.

Аутентификация

Видов аутентификации на самом деле дофига. Давайте разбираться.

Аутентификация по паролю

HTTP Authentication
Basic

Максимально простая штука. В HTTP-заголовке Authorization (о протоколе HTTP подробнее здесь) в незашифрованном виде (base64) передаются логин и пароль. Понятно, что штука эта небезопасная, но по HTTPS становится вполне сносной.

Digest

Чуть сложнее. Сервер отдает клиенту некое уникальное значение nonce, а клиент им хэширует пароль MD5

Windows authentication

Даже не буду подробно рассматривать этот вариант. Там тоже пароль в чистом виде не передается, и в этом смысле оно похоже на Digest, но работает только в Active Directory

Прочие варианты аутентификации по паролю

Это не то чтобы стандарт, но используется довольно часто. Логин с паролем передаются на сервер POST-запросом, он их проверяет и отдает токен, который браузер кладет в cookies и использует впоследствии в каждом запросе.

Еще есть вариант, что логин и пароль передаются в заголовке Authorization, а дальше происходит то же самое.

Аутентификация по сертификату

Тоже достаточно простая штука. На стороне клиента хранится сертификат, подписанный каким-то центром сертификации, гарантирующим его подлинность (CA, Certificate Authority).

Клиент передает сертификат серверу, а тот проверяет, подписан ли он доверенным CA, действителен ли он (не просрочен ли) и не отозван CA.

Аутентификация по ключу

Тут никаких логинов / паролей нет, а есть некий ключ (API key), который генерится на сервере заранее. Чаще всего клиент при каждом запросе в заголовке Authentication передает что-то типа Authentication: Bearer <token> . Понятно, что такое должно работать только по HTTPS, иначе заголовки можно будет перехватить.

Авторизация по токенам

Такое часто используется при построении распределенных систем, где одно приложение (service provider) делегирует аутентификацию другому приложению (identity provider). К примеру, многие сервисы делегируют аутентификацию социальным сетям (это когда мы гугл-учеткой аутентифицируемся, к примеру). Называется это все SSO (Single Sign-On).

Реализация такова — клиент аутентифицируется каким-то способом в identity provider (например, логином и паролем в Google), identity provider отдает сервис-провайдеру токен, который он использует для идентификации, аутентификации и авторизации пользователя.

Форматы токенов

Понятно, что суть одна, отличаются только форматы.

Simple Web Token (SWT)

Это токен формата закодированной HTML-формы.

JSON Web Token (JWT)

Этот токен состоит из трех блоков, разделенных точками: первые два (заголовок и набор полей) закодированы base64 и передаются как JSON (как неожиданно). Третий блок — это подпись, их подтверждающая.

Security Assertion Markup Language (SAML)

Это такие токены в формате XML. Используются редко, их прикол в том, что они содержат механизм для подтверждения владения токеном, что позволяет предотвратить их перехват.

OAuth / OpenID Connect

Вообще, это не метод аутентификации, а способ получения доступа одного приложения к другому от имени пользователя. Но с помощью этого стандарта аутентификацию реализовать все же можно.

Работает это примерно так:

  • пользователь дает разрешение приложению на доступ к определенному ресурсу и получает грант (обычно пара username/password)
  • приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант
  • приложение использует этот токен для получения требуемых данных от сервера ресурсов

Вывод

А вывода нет :) мы просто узнали, чем отличаются идентификация, авторизация и аутентификация и рассмотрели самые популярные варианты аутентификации.

Я специально не вдавался в подробности, потому что пишу в основном для начинающих разработчиков. А господа сеньоры и так все это знают (а не знают — прочитают, к примеру, здесь) — хорошая статья об этом всем с подробностями.

Stay tuned! Новые статьи не за горами.