Разбираем OAuth2 и OpenID Connect

Разрабатывая приложения (веб, мобильное, api, cli, tv и т.д.) чаще всего приходится реализовывать механизм аутентификации. Работая в микросервисной среде, механизм OAuth2 получил особую популярность и распространенность, так как в микросервисной архитектуре, необходимо строить сервисы так, чтобы они были без состояния (Stateless). А авторизация и аутентификация по средству Токенов, как раз предоставляет механизм авторизации без состояния. Также, стоит различать механизм Авторизации и Аутентификации. Авторизация - это когда мы удостоверяем пользователя, по логину и паролю, по паспорту или по другому документу. Аутентификация - в свою очередь, определяем, какие права и привилегии имеет пользователь в нашей системе (создавать, читать, редактировать, удалять). Сам механизм OAuth - был создан, чтобы делегировать Авторизацию другим пользователям. Например, у нас есть здание, и чтобы обеспечить способ Авторизации пользователей, мы можем выдать им бейджы (ID) или пропуск с магнитом. Тем самым, используя Токены или ID - можем проходить Авторизацию быстро. OAuth2 Roles Когда работаем с OAuth2, работаем с такими понятиями как Resource Owner (Пользователь), Resource (сами данные), Resource Server (API, microservice), Authorization Server - сервер, который Авторизует, и выдает Токены пользователю, для доступа к API и Client - которому требуются данные. Стоит понимать, что Токены используются сугубо для API. Это надо запомнить и принять. Tokens Это формат передачи данных. Разделяется на два больших вида: Access Token и Refresh Token. Access Token - принято делать кратко-живущим, так как если он утечет, то отозвать его будет невозможно, пока она не истечет. Refresh Token - необходим, чтобы перевыпускать Access Token. Данный Токен ни где не светят, чтобы он не утек. Плюс, вы можете подсчитывать, сколько активных Refresh Token'ов у пользователя, когда вы хотите реализовать логику как у Evernote скажем, что по бесплатному плану, у вас могут быть подключены, не более чем 3 девайса (ака - 3 Refresh Tokens). Затем, вы можете в БД хранить список отработанных Refresh Token, если поймете, что пользователь скомпрометирован. Остается дождаться, пока истечет Access Token. А еще, в Refresh Token, можете зашить какой ни будь Fingerprint, для доп анализа. И если в один момент времени, идут вызовы Refresh Token, с разных стран - это сигнал для реакции. Scopes Это синоним должностным инструкциям, по сути, права пользователя. Grant Types Это самая главная часть механизма в OAuth. Когда вы реализуете механизм аутентификации по протоколу OAuth, вам в первую очередь, необходимо согласовать, какой именно Flow авторизации вы будете реализовывать. Чаще всего используются: Client Credentials, Authorization Code, Device Code, Refresh, Password&Implicit. Данная тема большая и обширная. Более детально, данную часть, я разобрал в - видео формате Стоит также понимать, что Токены, предназначены для того, чтобы получить доступы к API (Resource). Полную версию материала, с примерами, Вы можете посмотреть в формате видео. Если есть вопросы - задавайте, отвечу.