Сохранение токена обновления Spring OAuth2RestTemplate

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

В вашем случае сначала, когда вы нажимаете "/oauth/token" (конечная точка по умолчанию) вместе с секретом клиента и идентификатором клиента и остальными учетными данными пользователя, алгоритм проверяет данные пользователя в БД и соответствует секрету и идентификатору, представленным в заголовке запроса. Если все пойдет хорошо, он сгенерирует тип носителя — токен доступа и обновления и будет хранить эти токены в разных коллекциях в базе данных. . Вы можете использовать MongoTokenStore, если вы используете MongoDb для хранения и доступа к сохраненным токенам.

Далее вам необходимо настроить WebSecurity/AuthorizationServer/ResourceServer для проверки токенов конечных точек и токенов заголовков, аутентификации и авторизации пользователей и предоставления действительных токенов доступа к ресурсу соответственно.

Наконец, когда у вас есть действительный токен доступа и вы попадаете в API с правильным запросом заголовка, сервер предоставляет вам разрешение на доступ к ресурсу!

Это базовая функциональность OAuth2.0.

Обычно токены доступа имеют более короткое время жизни, в то время как токены обновления имеют сравнительно большее время жизни. После истечения срока действия токена доступа новый токен доступа может быть сгенерирован с использованием токенов обновления. Если срок действия токенов обновления истек, вам нужно снова нажать API «/oauth/token», завершить цикл потока и снова сгенерировать токены. После истечения срока действия, когда вы нажимаете API с существующим токеном доступа, они удалены из коллекции. Это стандартная архитектура этого механизма, в остальном вы можете создавать собственные классы и изменять их функциональность в соответствии с вашими потребностями! Эта архитектура достаточно безопасна и является хорошей практикой.

Скриншот блок-схемы

Проверьте это сообщение на digitalocean.

Правки ----

1. Лично я использовал MongoDB, где сделал две коллекции — AuthAccessTokens и AuthRefreshTokens, а именно там, где хранились эти две. Объект Access Token имеет идентификатор связанного RefreshToken, который помогает сопоставить их вместе. Остальное пользовательская дополнительная информация. также можно добавить с помощью TokenEnhancer. Поэтому токены всегда будут присутствовать в БД, если не истек срок их действия. И с точки зрения непрофессионала, если вы просто сосредоточены на бэкенде, вы всегда можете проверить свои токены доступа, нажав «/oauth/token» с правильными учетными данными пользователя, и он вернет назначенный токен, извлекая его из БД, иначе, если вы разрабатываете полный стек после создания токенов на первом этапе, просто сохраните их на стороне клиента либо в локальном хранилище браузера, либо в приложении. И если вы хотите намеренно завершить сеанс, например, в Logout, просто удалите эти токены из соответствующих коллекций.