В основном архитектура OAuth2 используется для сторонней аутентификации и авторизации. В этом механизме учетные данные остаются защищенными и не передаются, пока все работает на токенах! Но вы можете использовать его для неявной работы и для вашей собственной аутентификации.
В вашем случае сначала вы нажимаете " / oauth / token " (конечная точка по умолчанию) вместе с клиентом-secret и client-Id и остальные учетные данные пользователя. Алгоритм проверяет данные пользователя в БД и сопоставляет секрет и Id, присутствующие в заголовке запроса. Если все пойдет хорошо, он сгенерирует тип носителя - токен доступа и обновления и сохранит эти токены в разных коллекциях в базе данных. Этот конкретный пользователь сопоставляется с этими токенами и может обращаться к / api только с их использованием. ,Вы можете использовать MongoTokenStore, если вы используете MongoDb для хранения и доступа к сохраненным токенам.
Далее необходимо настроить WebSecurity / AuthorizationServer / ResourceServer для проверки конечных точек и токенов заголовков, аутентификации и авторизации пользователей и предоставления действительных токенов. доступ к ресурсу соответственно.
Наконец, когда у вас есть действительный токен доступа и вы нажали api с правильным запросом заголовка, сервер предоставляет вам разрешение на доступ к ресурсу!
Это базовая функциональность OAuth2.0.
Обычно токены доступа имеют более короткое время жизни, в то время как токены обновления имеют сравнительно большее время жизни. По истечении срока действия токена доступа можно создать новый токен доступа с помощью токенов обновления. Если срок действия обновленных токенов истек, вам нужно снова нажать на API « / oauth / token », завершить цикл обработки и снова сгенерировать токены. После истечения срока действия, когда вы нажмете на API с существующим токеном доступа, они будут удаленыиз коллекции. Это стандартная архитектура этого механизма, в остальном вы можете создавать собственные классы и изменять их функциональность в соответствии с вашими потребностями! Эта архитектура довольно безопасна и является хорошей практикой.
Блок-схема снимка экрана
Проверьте этот пост из digitalocean .
Редактирует ----
- Лично я использовал MongoDB, где я сделал две коллекции - AuthAccessTokens и AuthRefreshTokens, именно там, где эти два хранились. Объект токена доступа имеет идентификатор связанного RefreshToken, который помогает сопоставить эти два элемента вместе. Отдых на заказ дополнительная информация. также может быть добавлен с помощью TokenEnhancer. Поэтому токены всегда будут присутствовать в БД, если не истек срок их действия. И с точки зрения непрофессионала, если вы просто сосредотачиваетесь на материалах Backend, вы всегда можете проверить свои токены доступа, нажав « / oauth / token » с правильными кредитами пользователя, и он вернет назначенный токен, выбрав его изDB, иначе, если вы разрабатываете полный стек после генерации токенов на первом шаге, просто сохраните их на стороне клиента либо в локальном хранилище браузера, либо в приложении. И если вы хотите сознательно завершить сеанс, как, например, при выходе из системы, просто удалите эти токены из соответствующих коллекций.