Pull to refresh

Comments 12

Наверное, я плохо прочёл текст, но мне показалось, что там говорится, что аутентификация — это определение «кто попало»/ «не кто попало», а авторизация -определение «кто именно». На самом деле немного наоборот аутентификация это «кто именно» а авторизация «какие права»
В моём понимании, например, ступени такие:
  • идентификация — понимаем, кто это (ввод логина);
  • аутентификация — убеждаемся, что этот кто-то действительно он самый (ввод пароля);
  • авторизация — наделяем пользователя необходимыми правами.
Я затрудняюсь, на самом деле, четко сказать что за чем стоит, описывая происходящее в терминах идентификации, аутентификации и авторизации. Слишком абстрактные понятия, иногда происходит и то и другое сразу, а иногда что-то одно внутри чего-то другого.

С аутентификацией и идентификацией проблема в том, что способы аутентификации без идентификации весьма редки. Watermarking возможно можно отнести к одному из них:

en.wikipedia.org/wiki/Category:Watermarking

В любом случае, с идентификацией на мой взгляд несколько проще, ее и с теми что на «а» не спутаешь, и само ее название дает неплохую интуицию насчет того что это.
Я на этом пункте перестал читать текст. Т.к. автор путает основные термины, то и дальше будет каша.
Собственно, не только автор путает термины, путаница с терминами начинается с самого их определения, взять википедию, например.

> Authentication is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity.

Описание, мягко говоря, непростое для понимания.
Дальше с этим пытаются бороться, поясняя:

> In contrast with identification, which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing's identity, authentication is the process of actually confirming that identity.

То есть аутентификация — это не идентификация пользователя, мы не определяем кто он конкретно, но подтверждаем что он тот кем себя назвал.

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

> It might involve confirming the identity of a person by validating their identity documents, verifying the authenticity of a website with a digital certificate,[1] determining the age of an artifact by carbon dating, or ensuring that a product is what its packaging and labeling claim to be. In other words, authentication often involves verifying the validity of at least one form of identification.

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

И да, везде про аутентификацию написано длинно, сложно и на нее старательно пытаются навесить функции авторизации и идентификации ей не свойственные. Из-за чего и начинается путаница.
везде про аутентификацию написано длинно, сложно и на нее старательно пытаются навесить функции авторизации и идентификации ей не свойственные. Из-за чего и начинается путаница

Я себе запомнил так:

регистрация = заказ столика в ресторане

идентификация (ввод логина) = пришёл, подходишь к администратору ресторана, говоришь я здесь заказывал столик

аутентификация (ввод пароля) = администратор говорит — докажи что ты это ты) Ты показываешь права или паспорт

авторизация = администратор смотрит в список гостей и говорит — ваш вон тот столик у туалета
да, весьма наглядно и доступно, мне нравится

потенциально можно докопаться до последовательности, идентификация происходит вместе с аутентификацией, а отделить их друг от дружки можно, заменив, скажем, ресторан на клуб а представление на флаер, по которому можно аутентифицироваться не идентифицируясь
но учитывая что это весьма спорная экзотика, иллюстрация с рестораном очень даже

уволоку для будущих разъяснений, с вашего позволения
OAuth — это протокол авторизации, а не аутентификации (https://ru.wikipedia.org/wiki/OAuth), а вот OpenID Connect — это протокол аутентификации по верх протокола авторизации (такая вот чехарда), т.к. наличие клэймов в JWT-токене (конкретно в id_token) гарантирует только само наличие, а вот автрозизацией уже будет заниматься приложение доверяющее, например, списку ролей в клэймах
Даже в спецификации OAuth 2.0 написано, что это протокол авторизации, но я боюсь что это продолжение все той же путаницы аутентификации с авторизацией, даже спеки могут стать ее жертвами.

OpenID Connect по спецификации вообще слой идентификации поверх OAuth 2.0. Но тут, понятно, писать что это протокол авторизации поверх другого протокола, который тоже описан как протокол авторизации, было бы странно.

Снова к описанию из вики:

> Authorization is the function of specifying access rights/privileges to resources related to information security and computer security in general and to access control in particular.[1] More formally, «to authorize» is to define an access policy.

Пользовательские роли, описывающие его access rights/privileges оказываются как раз среди клеймов в JWT, то есть в OpenID Connect.

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

OpenID Connect — это протокол аутентификации и, возможно, авторизации пользователя поверх протокола авторизации приложения.
Да, спасибо, сам я это сформулировать не осилил.
OAuth авторизует приложение и аутентифицирует клиентское приложение, OpenID Connect авторизует пользователя для приложения.
tools.ietf.org/html/rfc6749#section-3.1

The authorization server MUST first verify the identity of the resource owner. The way in which the authorization server authenticates the resource owner (e.g., username and password login, session cookies) is beyond the scope of this specification.
Only those users with full accounts are able to leave comments. Log in, please.