OAuth авторизация авторизация

Question

Я полностью запутался в использовании OAuth и не уверен, как использовать oauth для моего сценария. На данный момент я использую «чистый» подход JWT, который выглядит так:

1. Клиент (Приложение JavaScript) отправляет логин и пароль на мою Rest-Endpoint (Сервер (Java)).
2. Сервер проверяет информацию пользователя, считывает / генерирует некоторые роли пользователя и оборачивает ее в токен JWT (с секретом)
3. Сервер отправляет токен JWT обратно клиенту
4. Клиент выполнит дополнительные Rest-Calls с заголовком Authorizationen
5. Сервер проверяет токен с личным секретом и общим доступом на основе ролей / пользователя

Теперь я думаю об использовании OAuth, но я запутался, как использовать его для реализации сценария.

1. Я зарегистрировал приложение на «auth0».
2. Я использую библиотеку JS для перенаправления в процесс входа в систему auth0, входа через учетную запись auth0 и использования id_token и access_token

= я могу отправить id_token (JWT с RSA256) моему API для отдыха, проверить его с помощью публичного сертификата и извлечь некоторую информацию о пользователе

но:

а) Я прочитал, что не должен использовать id_token для доступа к моему API. Вместо этого я должен использовать access_token (который не в формате JWT и не даст мне никакой информации о пользователе) и использовать access_token для запроса информации о пользователе? Как быть с каждым запросом?!

б) Я не вижу смысла, когда в игру вступают роли пользователя. Когда у меня есть некоторые операции (остальные конечные точки), которые разрешены только для «администраторов» или «клиентов». Я не вижу возможности определить их.

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

Answer 1

a) Звучит так, как будто вы получаете непрозрачный access_token, а не JWT. Вам нужно будет создать API в Auth0 (аналогично приложению / клиенту, которые вы уже создали). Затем вы передаете этот идентификатор в параметре audience при аутентификации. Затем вы должны вернуть JWT, и он будет иметь параметр sub, который является идентификатором пользователя Auth0, который может помочь вам определить, кто пользователь. Я полагаю, что вы также можете использовать правила Auth0, если вам нужно добавить больше идентификационной информации в токен. Смотрите здесь для полного объяснения непрозрачного токена доступа JWT: https://auth0.com/docs/tokens/access-token

б) Роли сложны. Я полагаю, что Auth0 предложит вам создать области для вашего API, а затем запросить области, необходимые при входе в систему. Правила Auth0 будут затем использоваться как своего рода «клей» для настройки областей, которые были запрошены, но не разрешены для аутентифицированного пользователя. У них также есть расширение авторизации, которое вы можете использовать, чтобы облегчить некоторые из них. Другим вариантом может быть сохранение информации о роли в метаданных пользователя и использование правил для помещения этой информации в токен. Наконец, мы выбрали не использовать Auth0 для определения наших ролей. Мы разрешаем Auth0 аутентификацию, а после аутентификации проверяем доступ в нашей системе на предмет авторизации. Много вариантов.

Answer 2

а) Оба используемых токена должны быть в формате JWT, и вы должны использовать access_token для аутентифицированных запросов. Access_token не обязательно содержит информацию о пользователе, поэтому на стороне сервера вы обычно можете решить, что токен отправлен сервисом токенов и является действительным. Если все эти проверки пройдены, вы должны принять их как аутентифицированного пользователя.

b) Роли пользователей могут быть помещены в раздел полезных данных access_token в качестве дополнительного требования (например, роль = администратор, автор данных или роль = клиент, читатель списка), как и многие другие.

Надеюсь, это поможет.