Авторизация через 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 и также для других ключей