Как аутентифицировать основное приложение, когда оно основано на OAuth API

Question

Я начинаю новый веб-проект и намереваюсь сделать его на основе API; я хочу сначала создать API, аутентифицированный через OAuth, а затем создать веб-сайт и, возможно, мобильные приложения, которые используют API для обработки данных. Я также планирую открыть API для публики.

Вот моя проблема; Я изо всех сил пытаюсь понять, как аутентифицировать эти «официальные» приложения, сделанные мной, включая основной сайт.

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

Я считаю, что твиттер использует собственный API для запуска twitter.com, и у меня складывается впечатление, что этот подход становится вполне нормальным, поэтому должен быть стандартный подход.

Должно быть, я что-то упустил, но что?

Answer 1

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

Правильно, что twitter.com используетих собственный API.Но они не используют OAuth на своем собственном сайте.Когда вы находитесь на twitter.com, их API доступны через аутентификацию cookie.Проще говоря: вы вошли в систему.

Когда вы уходите с twitter.com, вы должны использовать OAuth.Теперь приложение использует API от имени пользователя.

Подводя итог.Вам не требуется OAuth для того, чтобы ваш «собственный» веб-клиент использовал ваши собственные API.Вам нужен OAuth или какой-то другой механизм авторизации для публикации ваших API, и он также пригодится для ваших собственных «официальных» приложений.

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

Answer 2

Хост две версии «API». Один из них сопоставлен с внешним доменом api.yoursite.com, и для него включена проверка подлинности OAuth для проверки подлинности всех запросов. Другая внутренняя версия доступна только в пределах вашего пула серверов, ваших официальных приложений. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 100 * * * * * * * * * * * * * * * * * * * * *

Если вы хотите, чтобы одно и то же приложение управляло как внешними, так и внутренними вызовами, вы можете выбрать

1. различает внешние и внутренние запросы на основе входящих IP-адресов
2. Реализация вашего API для принятия одного из"VIP-пропусков" или токенов OAuth для аутентификации. Внешние приложения используют токены OAuth для выполнения действий от имени определенных пользователей. Официальные приложения используют «VIP-пассы» для выполнения действий от имени любого пользователя.