Блог

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

Моей первой мыслью было использовать для этого базу данных PostrgeSQL в AWS и реализовать аутентификацию самостоятельно, но это означает, что пользователям придется зарегистрироваться и создать новый профиль, что означает запоминание еще одного <имя пользователя / адрес электронной почты, пароль>. Пытаясь избежать этого, я немного прочитал об OAuth 2.0 и OIDC и о том, как его можно использовать для аутентификации и авторизации пользователей, не выполняя ни одну из этих задач самостоятельно, а скорее делегируя задачу OIDC. Я создал бесплатную учетную запись с Auth0 и думал об использовании ее для интеграции с OIDC, но после прочтения около 40 страниц «Руководства по интеграции с OIDC», которое они предлагают бесплатно, я не мог знать, смогу ли я различать свою пользовательскую базу по этим ролям или тегам, как я упоминал. Я просто следовал инструкциям в учебном руководстве и пытался понять, как работает поток аутентификации, но это не дало мне никакой информации по моему вопросу.

Итак, в целом, что я хочу знать: возможно ли реализовать это с помощью Auth0 (бесплатная учетная запись) без использования стороннего решения для баз данных (такого как PostgreSQL с AWS)? Если нет, на что бы вы порекомендовали мне обратить внимание? Предпочтительно решение, которое позволит мне различать два типа пользователей, но в то же время использовать преимущества реализации OIDC, например, Google.

Здесь есть 2 отдельных решения:

АУТЕНТИФИКАЦИЯ НА РАБОЧЕМ СТОЛЕ

Двумя стандартными требованиями являются:

• Используйте поток кода авторизации (PKCE)
• Войдите в систему через системный браузер

Вы прослушиваете ответ на вход с помощью одного из этих механизмов (я предпочитаю последний):

• Веб-сервер с обратной связью
• Уведомление операционной системы о закрытой схеме URI

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

АВТОРИЗАЦИЯ API С ПОМОЩЬЮ РОЛЕЙ

Вам нужно сделать роли доступными для API через утверждения. Это может быть сделано любым из этих механизмов (я предпочитаю последний):

• Включение ролей в токены доступа через Auth0
• Заставьте API считывать роли пользователей из собственной базы данных

В моем сообщении в блоге авторизации обсуждается создание объекта claims простым в расширении способом. Основная цель обычно заключается в том, чтобы обработка API OAuth привела к созданию объекта, подобного этому:

 class UserPrincipal {

  // The technical user id from the access token 
  string sub;

  // The user id from your own database
  string userId;

  // The user's roles
  string[] roles;

}
  

Учитывая этот объект, вы можете делать подобные вещи:

• При необходимости используйте авторизацию на основе ролей
• Предоставляйте пользовательские ресурсы после входа в систему из данных вашего приложения

ПОДВОДЯ ИТОГ

Auth0 будет соответствовать некоторым вашим требованиям и может быть всем, что вам нужно в первые дни. Однако в какой-то момент вам, вероятно, потребуется управлять пользовательскими данными, отличными от OAuth, в вашем API.

Рад ответить на любые последующие вопросы..