У нас есть мобильное приложение, которое использует OTP на основе SMS для входа в систему.До сих пор, поскольку приложение считалось доверенной стороной, у нас не было потока авторизации, как в OAuth.Наш поток входа в приложение был похож на WhatsApp, где пользователь вводит телефонные номера, получает otp и вводит otp для входа в систему.
Теперь мы планируем открыть платформу для третьих сторон и рассмотрим использование OAuth2 для авторизации.Новая система аутентификации также поддерживает OpenID connect.Но OpenID connect по-прежнему включает в себя перенаправления браузера, которых мы хотим избежать для нашего исходного приложения.Мы не хотим поддерживать две отдельные системы здесь (для нашего приложения и сторонних клиентов), поэтому нам хотелось бы использовать oauth + openID.
Один из обсуждавшихся потоков был с некоторыми пользовательскими типами ответов и типами предоставления, как описано ниже:
- Пользователь вводит номер телефона
- Запрос https на
/authorize выполняется с follow_redirect = false с использованием HTTP-клиента в качестве агента (например, вместо okhttpбраузера): response_type=otp (для нашего response_type разрешено только наше внутреннее приложение) redirect_uri=myapp://auth (этот URI будет внесен в белый список в конфигурации клиента на нашем сервере oauthв соответствии с требованиями спецификации)
- Поскольку, follow_redirect = false , ответом на этот запрос будет сама директива перенаправления (
302 Found) с Locationзаголовок, содержащий otp-binding-code, который извлекается. - Пользователь получает OTP через SMS и входит в экран OTP
- Вызов
/token выполняется следующим образом: grant_type=otp (тип предоставления otp будетразрешено только для внутреннего приложения) otp_code=otp-binding-codeotp=<user-entered-value>response_type=token+id_token (то есть, как при подключении OpenID)
- Приложение возвращается
access_token, refresh_token, id_token. - Приложение извлекает и проверяет заявки от
id_token и использует access_token для вызовов API.
Я считаю, что это похоже на resource owner password Grant oauth, но может бытьс некоторыми взломами.Но приемлемый ли это способ?и пропущены ли какие-либо соображения безопасности?Для сторонних приложений мы будем использовать стандартный поток (открыть браузер, отобразить форму входа в систему, отобразить форму согласия, получить код авторизации и т. Д.)
Другой способ, который мы рассмотрим, это исключить /authorize из этого.Отдельная конечная точка POST /otp используется для генерации OTP .., а конечная точка /token используется, как описано выше, для ее проверки и получения токенов.
Примечание: Важные параметры, такие как client_id, state и т. Д. Для краткости не показаны