Авторизация через OAuth2.0/OpenIDConnect

Авторизация через OAuth2.0/OpenIDConnect

Аккаунт может иметь свой SSO. Мы можем работать по OAuth2.0/OpenIDConnect флоу Authorization Code.

tb_client_host - клиентский домен или наш поддомен ведущий на аккаунт клиента

Обязательные поля

  • Хост - адрес по которому будет доступен сервис клиента
  • Uid - публичный ключ oauth приложения, который должен предоставить клиент
  • secret key - секретный ключ от oauth приложения, который должен выдать клиент. Нужен для получения токена

Наш callback url /auth/sso/oauth/callback

Если клиентский сервис поддерживает OpenId Connect Discovery(получение конфигурации через /.well-known/openid-configuration) то нужно только включить OpenID на этом настройка почти завершена(см дальше про соответствие ключей)

Опции

  • Redirect users to auth login - это опция на входе в Teachbase отправляет на вход через клиентский сервис минуя нашу страницу входа
  • OpenID connect - говорит о том, что мы будем работать по этому протоколу, иначе по OAuth2.0

Дополнительные поля (можно пропустить если работаем через OpenId Connect Discovery)

  • Autrhorized url - url куда перенаправлять пользователя для создания сессии
  • Token url - адрес по которому можно будет запросить токен
  • User info endpoint url - адрес по которому можно будет запросить данные пользователя с полученным токеном. Мы отправляем GET запрос. Если мы работаем по OpenID, то там получение данных пользователя описаны в спецификации и как правило будут одинаковыми. Но если мы работаем по OAuth2.0 то после получение токена, наша система отправит GET запрос с заголовком Authorization: Bearer <token> на info endpoint url для получения данных о пользователе, чтобы можно было по email или phone найти такого в системе и выполнить вход. Сервер SSO должен вернуть JSON объект пользователя, например

    {"id": 123, "email": "example@example.ru"}

    Соответствие ключей
    Клиент может возвращать данные, которые нам нужны для аутентификации пользователя, в структуре с ключами "понятными" для них, чтобы наша система поняла из каких ключей, что получать нужны поля соответствия. Например клиент возвращает

  • {"user_email": "example@example.ru"}

    Что мы поняли откуда получить email нужно заполнить поле User email key значением user_email и также для других ключей