Понимание аутентификации токена OAuth2

1. Введение

В этом руководстве мы будем понимать аутентификацию OAuth2 Token , так что только аутентифицированные пользователи и приложения получают действительный токен доступа, который впоследствии можно использовать для доступа к авторизованным API (которые являются ничем иным, как защищенными ресурсами в терминах OAuth) на сервере.

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

2. События, связанные с аутентификацией токена

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

1. Клиентское приложение сначала запрашивает разрешение на авторизацию у пользователя (владельца ресурса), поскольку мы часто видим всплывающее окно авторизации для авторизации или запрета доступа к данным какого-либо другого приложения. Например, Goibibo запрашивает доступ к друзьям из вашей учетной записи Facebook.
2. Как только пользователь авторизуется, нажав «Авторизовать» во всплывающем окне, клиентское приложение (Goibibo) получает грант авторизации.
3. Затем клиентское приложение (Goibibo) запрашивает у сервера авторизации (Facebook) токен доступа вместе со своей идентификационной информацией и разрешением авторизации, полученным на предыдущем шаге.
4. Если клиентское приложение аутентифицировано и разрешение на авторизацию признано действительным, Сервер авторизации (через Facebook) предоставляет / выдает токен доступа клиентскому приложению (Goibibo).
5. Затем клиентское приложение (Goibibo) получает доступ к защищенным ресурсам (друзьям из приложения facebook), передавая затем токен доступа на сервер ресурсов (через Facebook) до истечения срока действия токена.

3. OAuth2 Роли

Ниже перечислены делегированные роли в реализации OAuth —

1. 1. владелец ресурса — объект, способный предоставить доступ к защищенному ресурсу. Если вы вошли в Goibibo и хотите получить доступ к друзьям из вашей учетной записи Facebook, вы являетесь владельцем ресурса, которому необходимо предоставить разрешение на авторизацию.
   2. сервер ресурсов — сервер (Facebook), на котором размещены защищенные ресурсы, который может принимать и отвечать на запросы защищенных ресурсов с помощью токенов доступа. Это означает, что список друзей — это один из ресурсов, размещаемых на сервере (Facebook), доступ к которому могут получить другие сторонние приложения (Goibibo).
   3. клиент — приложение (Goibibo), делающее защищенные запросы ресурсов от имени владельца ресурса (пользователя) и с его авторизацией. Мы определяем все такие авторизационные гранты в контексте как —
   4. Это означает, что Gobibo как клиентское приложение может получить доступ к списку друзей администратора на сервере ресурсов (Facebook).
   5. сервер авторизации — сервер, который предоставляет токен доступа клиентскому приложению на основе идентификатора клиентского приложения и гранта авторизации, полученных владельцем ресурса (пользователем).
      

4. Авторизация Гранты

OAuth2 предоставляет четыре типа авторизационных грантов —

4.1 Код авторизации

• Используется в приложениях на стороне сервера, поэтому конфиденциальность с обеих сторон поддерживается.
• Самый распространенный из всех.
• Перенаправление на основе потока.
• Запрос авторизации пользователя направляется через пользовательский агент (веб-браузер), и клиентское приложение должно быть достаточно способным взаимодействовать с пользовательским агентом и получать код авторизации с сервера авторизации на другом конце.

4.2 Неявный

• Несколько похоже на тип авторизации кода авторизации.
• Чаще используется для мобильных приложений и веб-приложений.
• Конфиденциальность подвергается риску на стороне клиента, так как код авторизации хранится локально вместе с пользовательским агентом перед передачей его клиентскому приложению. Это может быть выставлено другим приложениям на устройстве пользователя.
• Не поддерживает Обновить токены.

4.3 Учетные данные пароля владельца ресурса

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

4.4 Учетные данные клиента

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

5. Магазин токенов

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

1. InMemoryTokenStore — токен хранится в памяти сервера, поэтому существует риск потери токенов при перезапуске сервера авторизации.
2. JwtTokenStore — все данные авторизации и предоставления доступа закодированы в самом токене, и такие токены нигде не сохраняются. Такие токены проверяются на лету с помощью декодера и зависят от JwtAccessTokenConverter .
3. JdbcTokenStore — данные токена сохраняются в реляционной базе данных. С этим хранилищем токенов мы в безопасности в случае перезапуска сервера авторизации. Токены также могут быть легко распределены между серверами и могут быть отозваны. Обратите внимание, что для использования JdbcTokenStore нам понадобится зависимость «spring-jdbc» в пути к классам.

6. Обновить поток токенов

После истечения срока действия токена доступа по истечении заданного промежутка времени (119 в соответствии с приведенным ниже примером) мы можем сгенерировать новый действительный токен доступа, используя токен обновления . Токен обновления появляется, когда выдан оригинальный токен доступа, как мы видим ниже.

Нажмите здесь, чтобы перейти к официальной документации OAuth2