OAuth 1.0 - как реализовать как двухъядерную, так и трехстороннюю аутентификацию?

Я внедрил провайдера OAuth 1.0a и у вас есть клиенты OAuth, которые могут успешно пройти аутентификацию против него, используя стандартную трехстороннюю аутентификацию.

OAuth защищает REST API на моем сервере, и у меня есть мобильное приложение, которое его использует.

В моем мобильном приложении у меня есть некоторые функции (конечные точки), которые могут быть доступны даже до того, как конечный пользователь войдет в свою личную учетную запись. Некоторые пользователи могут даже просто использовать общедоступные функции без создания учетной записи.

Я хотел бы защитить OAuth как "общедоступными", так и "закрытыми для пользователя" конечными точками.

Поэтому я думаю, что путь к использованию - использовать OAuth следующим образом (но я могу ошибаться... очень неправильно).

Мобильное приложение сначала выполнит двухстороннюю аутентификацию, как только приложение будет запущено в первый раз. Таким образом, мобильное приложение получит "двухногий" токен. Мобильное приложение будет использовать этот токен для доступа к общедоступным конечным точкам.

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

1) Первый вопрос. Имеет ли это смысл? Есть ли еще один хороший способ сделать это?

Теперь моя проблема: как я могу (поставщик сервера) узнать, хочет ли мобильное приложение аутентифицироваться с помощью двухногих? Полагаю, как поставщик, мне нужно знать, что для того, чтобы решить, буду ли я перенаправлять клиента на логин форму для пользователя для заполнения (в случае с 3-мя ногами), или я просто выдам уже авторизованный токен запроса (в случае 2-ного), чтобы его можно было обменять на токен доступа (как для 3 -legged).

Моя идея заключалась в том, чтобы предоставить клиенту 2 пользовательских ключа: один для использования, когда они хотят двухногих, а один - для использования, когда им нужны 3-ночные. Я, как поставщик, я буду знать, какой поток предоставить на основе используемого мной ключа потребителя.

2) Второй (и последний вопрос). Это разумно? Есть ли лучший способ его реализовать?

Я видел людей, реализующих двухногий, просто позволяя клиенту (потребителю) отправлять пустой токен доступа. Так ли это?

Спасибо.

Ответ 1

OAuth предназначен для управления доступом к вашему REST API сторонними приложениями. Например. другая компания разрабатывает приложение, которое будет потреблять ваш API. И вы не хотите, чтобы ваши клиенты предоставляли пароль этим сервисам сторонним организациям. В этом случае OAuth является решением. Если сторонних приложений нет, тогда не требуется OAuth.

Если у вас есть одна услуга и только ваши приложения, потребляющие ее, вам не нужно реализовывать какой-либо OAuth. Вам необходимо создать обычный механизм входа в систему (и, вероятно, правильный контроль).

Использование HTTPS достаточно для обеспечения взаимодействия конечных точек. Если вы хотите защитить содержимое хранилища в мобильном приложении или некоторых других пользователях REST, вам придется зашифровать его перед сохранением.

UPDATE: Если вы хотите защитить "конечную точку", то это решение должно быть трехсторонним OAuth. Решение с двумя ногами потребует установки стороннего приложения + вашего приложения OAuth (или lib) на пользовательское устройство. В противном случае пользователь может быть взломан подобным пользовательским интерфейсом и просто предоставить стороннему пользователю и пароль.