Вы часто слышите, как аутентификация и авторизация перечислены вместе на одном дыхании. Часто люди объединяют эти термины и просто говорят «auth». Неудивительно, что некоторые из нас путают эти два понятия. Если вы заботитесь о безопасности своего приложения и конфиденциальности пользователей, важно знать, что между этими двумя терминами есть разница. Так в чем разница и почему это важно?

Говоря об аутентификации (также называемой AuthN), думайте об идентичности. Аутентификация пытается ответить: «Это человек, о котором они говорят?» Это программный эквивалент паспорта или национального удостоверения личности. Или, говоря более реалистично, аутентификация - это процесс, похожий на тот момент, когда вы смотрите в лицо другого человека, чтобы узнать, что это ваш друг из колледжа, а не раздражающий сосед по второму этажу.

С другой стороны, авторизация (также называемая AuthZ) - это все о разрешениях. Авторизация отвечает на вопрос «что этому человеку разрешено делать в этом пространстве?» Вы можете считать его ключом от дома или офисным значком. Вы можете открыть входную дверь? Может ли назойливый сосед зайти в вашу квартиру по желанию? И еще, оказавшись в вашей квартире, кто сможет пользоваться туалетом? Кто может есть из вашего секретного хранилища печенья, спрятанного в кухонном шкафу?

Хотя связанные, аутентификация и авторизация - это совершенно разные проблемы. Может возникнуть соблазн объединить их в одну кучу, но обычно это приводит к тому, что одним из них пренебрегают. К сожалению, больше всего игнорируется авторизация. Легко понять почему.

В программном обеспечении вы не можете выполнить авторизацию без предварительной аутентификации. Если каждый пользователь не может делать все и все является публичным, вы должны уметь различать пользователей. Вот почему все начинается с аутентификации. Аутентификация - это очень заметный процесс: вы получаете форму входа или кнопку для использования федеративного поставщика удостоверений (вход в систему с помощью Google, Facebook, Twitter и т. Д.). внимание разработчиков. Когда вы привыкли думать об AuthN и AuthZ просто как об «Auth», после того, как вы потратили значительное количество времени на то, чтобы пользователи могли безопасно входить в систему, возникает соблазн думать, что вы в основном закончили со своим «auth».

На самом деле именно здесь начинается настоящая работа. Как только вы узнаете, что пользователь - это тот, кем он себя называет, вам нужно подумать, к чему он может получить доступ и какие операции он может выполнять. Это разрешение. Когда аутентификация прерывается (пользователь входит в систему), авторизация продолжается и продолжается, пока пользователь взаимодействует с вашим программным обеспечением. В этом процессе много тонкостей. Сколько существует разных ресурсов? К ним относятся одинаково или по-разному? Могут ли пользователи делиться ресурсами? Если да, то кто решает, что делиться, а что нет? Что происходит с общим ресурсом, когда его удаляет владелец? Этот список можно продолжить. Если вы не рассматриваете авторизацию как отдельный класс проблем, ваши пользователи столкнутся с множеством крайних ситуаций, которые могут или не могут привести к провалу PR для вашей компании.

Если вы не разделяете аутентификацию и авторизацию, вы рискуете создать много неудобств, если не ошибок в вашем программном обеспечении. В зависимости от того, что делает ваше программное обеспечение, AuthN или AuthZ могут быть более важными. Имеет смысл разрабатывать свое решение, полностью осознавая, какое из них какое.

Проиллюстрируем это на примере. Вы отвечаете за безопасность жилого комплекса. Ваша задача - сделать так, чтобы люди могли получить доступ к своим квартирам, и никакие нежелательные посетители не могли сделать то же самое.

Если ваша первая мысль - аутентификация, вы, вероятно, поставите у входа охранника, попросив всех предъявить свои удостоверения личности, чтобы войти. Теперь, когда у вас есть охранник, вы дадите охраннику список всех жильцов, чтобы только входят нужные люди. Проблема решена. Ой, но подожди! Вы вернулись с работы только для того, чтобы увидеть, что ваш надоедливый сосед сидит на вашем диване и ест из вашего секретного хранилища печенья. Охранник на входе ей явно не помешал, ведь она жительница дома. С точки зрения программного обеспечения это было бы эквивалентом зумомбирования или утечки личных изображений. Не такое уж и неслыханное.

Если вы подойдете к той же проблеме, что и авторизация, возможно, вместо того, чтобы выставлять охранника, вы вместо этого дадите каждому из своих арендаторов набор ключей. Каждый получит один и тот же ключ, чтобы открыть главную дверь, и дополнительный ключ, уникальный для каждой квартиры. Теперь надоедливая соседка может навещать вас только по приглашению, и печенье ей точно не достанется! Это определенно лучшее решение. Тем не менее, это еще не все. Что делать, если вы потеряете ключи? Что, если кто-то найдет ваши утерянные ключи и решит почувствовать себя как дома в вашей квартире? Вы бы не знали, потому что в этом случае вы больше никогда не попадете в здание. В программном обеспечении это будет то же самое, как если бы ваш бывший взломал вашу учетную запись электронной почты и сменил пароль. Не очень весело.

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

Первоначально опубликовано на https://authress.io 9 июня 2020 г.