Я внедрил провайдера OAuth 1.0a и у вас есть клиенты OAuth, которые могут успешно пройти аутентификацию против него, используя стандартную трехстороннюю аутентификацию.
OAuth защищает REST API на моем сервере, и у меня есть мобильное приложение, которое его использует.
В моем мобильном приложении у меня есть некоторые функции (конечные точки), которые могут быть доступны даже до того, как конечный пользователь войдет в свою личную учетную запись. Некоторые пользователи могут даже просто использовать общедоступные функции без создания учетной записи.
Я хотел бы защитить OAuth как "общедоступными", так и "закрытыми для пользователя" конечными точками.
Поэтому я думаю, что путь к использованию - использовать OAuth следующим образом (но я могу ошибаться... очень неправильно).
Мобильное приложение сначала выполнит двухстороннюю аутентификацию, как только приложение будет запущено в первый раз. Таким образом, мобильное приложение получит "двухногий" токен. Мобильное приложение будет использовать этот токен для доступа к общедоступным конечным точкам.
Когда (и если) пользователь просит войти в приложение, мобильное приложение выполнит трехстороннюю аутентификацию и получит "трехногий токен". С этого момента приложение забудет о предыдущем двухноменном токене и использует трехногий токен для доступа к публичным и частным конечным точкам.
1) Первый вопрос. Имеет ли это смысл? Есть ли еще один хороший способ сделать это?
Теперь моя проблема: как я могу (поставщик сервера) узнать, хочет ли мобильное приложение аутентифицироваться с помощью двухногих? Полагаю, как поставщик, мне нужно знать, что для того, чтобы решить, буду ли я перенаправлять клиента на логин форму для пользователя для заполнения (в случае с 3-мя ногами), или я просто выдам уже авторизованный токен запроса (в случае 2-ного), чтобы его можно было обменять на токен доступа (как для 3 -legged).
Моя идея заключалась в том, чтобы предоставить клиенту 2 пользовательских ключа: один для использования, когда они хотят двухногих, а один - для использования, когда им нужны 3-ночные. Я, как поставщик, я буду знать, какой поток предоставить на основе используемого мной ключа потребителя.
2) Второй (и последний вопрос). Это разумно? Есть ли лучший способ его реализовать?
Я видел людей, реализующих двухногий, просто позволяя клиенту (потребителю) отправлять пустой токен доступа. Так ли это?
Спасибо.
