Что возвращать после авторизации через API?
Я создаю сервер API, который будет использоваться мобильным приложением, над которым я буду работать позже. Я еще не видел ссылок на лучшие практики API, связанные с пользовательским потоком и возвращаемыми данными, даже после нескольких часов поиска.
Мой вопрос заключается в том, должен ли ответ API на вход в систему возвращать токен личного доступа с токеном обновления вместе с информацией о пользователе? Или я должен просто вернуть токен и сделать еще один вызов API для получения информации о пользователе.
Я мог бы просто делать то, что задумал, но я пытаюсь изучить лучшие практики, чтобы потом мне не приходилось настраивать много вещей.
Мне нужны предложения, а также хорошие ссылки, связанные с моим вопросом.
Спасибо.
Ответы 2
Это зависит от того, что вы используете для аутентификации. Если вы используете такие библиотеки, как Ларавель паспорт или JWT, у вас может быть конечная точка токена, которая возвращает токен доступа, токен обновления, срок действия и тип токена (носитель). Затем у вас может быть аутентифицированная конечная точка, которая будет использоваться для получения профиля пользователя на основе токена, переданного в заголовке запроса.
Однако, если вы просмотрите документацию для этих библиотек, в большинстве из них допускается использование токена генерировать вручную. Вы можете использовать это в пользовательской конечной точке, которая будет возвращать токен, а также профиль пользователя Паспорт Создать токен вручную.
Если вы используете JWT, вы также можете встроить несколько пользовательских свойств в сам токен. Клиент может получить информацию о профиле от самого JWT, не обращаясь к серверу. Паспорт ДОБАВИТЬ профиль в JWT
Если у вас есть собственный способ обработки аутентификации, вы можете передать токен, а также профиль пользователя в одном ответе.
В конце концов, вам решать, что вам больше подходит.
Лично я бы не стал использовать токены личного доступа для аутентификации мобильного приложения. Выберите тип предоставления пароля. Однако я бы «проксировал» конечную точку токена, чтобы у клиентов не было секрета для предоставления пароля. Вы должны прочитать о различных потоках и их вариантах использования.
В документации есть конфигурация для длительности токена. Для вашей проблемы с жадностью попробуйте этот Жрать прокси
Я так понял, что жрать не будет, если в ссылке определены порты. Что-то типа 192.168.1.2:8000 не подойдет. Поэтому я решил использовать laravel valet, чтобы порты не включались в ссылку, и это сработало.
И на сегодняшний день я решил просто вернуть то, что возвращает /oauth/token. Я мог бы изменить его, чтобы также возвращать другие данные пользователя, как только я начну работать над мобильным приложением.
Вы смотрели на OpenID Connect? Это еще один уровень поверх OAuth 2.0, обеспечивающий аутентификацию пользователя (OAuth 2.0 не распространяется на аутентификацию, он просто предполагает, что это происходит) и способы поиска информации о текущем пользователе. Он имеет концепцию ID_token в дополнение к токену доступа OAuth, а также предоставляет конечную точку /userinfo для получения информации о пользователе. Вы мог помещаете информацию о пользователе в свой токен доступа, но рекомендуется НЕ разрешать доступ к вашему токену доступа из JavaScript (т. е. использовать файлы cookie HTTP_ONLY для хранения вашего токена доступа).
Клиент говорил о вершине Google. Будет ли это возможной альтернативой OpenID connect? Я еще не исследовал это, но я сделаю это, как только выполню некоторые другие требования.
Я где-то читал, что предоставление пароля лучше для сторонних клиентов (в этом случае владелец API также владеет мобильным приложением). Так что я мог бы придерживаться этого. Я просто выясняю, почему жужжание не работает при публикации в /oauth/token. В любом случае, есть ли аргументы в пользу того, почему я должен выдавать токен личного доступа, а не предоставлять пароль? Мне нужно было сократить время жизни токена, поэтому я предполагаю, что токена личного доступа с длительным сроком службы не будет.