Внедрение аутентификации OAuth 2.0 для моего API

Я уже давно использую API-интерфейс Facebook (использует oauth 2.0 для аутентификации). Теперь мне нужно написать свой собственный API, который позволяет разработчикам подключаться к нему аналогичным образом. Я просмотрел различные библиотеки, но мне хотелось бы немного немного уменьшить, поэтому я решил бросить свой собственный. Глядя на код, я должен аутентифицировать пользователя на facebook, он выглядит относительно простым, но, пожалуйста, поправьте меня, если я уйду с пути.

Сначала мне нужно будет предоставить безопасную страницу, на которую потребитель должен будет перенаправить. например https://api.mydomain.com/oauth/authorize?client_id=CONSUMER_KEY&redirect_url=CALLBACK_URL. Пользователь будет проверять приложение, после чего я перенаправляю обратно к URL-адресу, указанному в URL-адресе обратного вызова, с помощью oauth_token в строке запроса. Я предполагаю, что могу просто создать случайную уникальную строку здесь для oauth_token и сохранить ее против пользователя для этого конкретного потребителя (EDIT: см. Ответ ниже, это должно быть уникальным для каждого потребительского приложения, а не для пользователя).

Этот шаг 1 вышел. Теперь мне нужно предоставить вторую защищенную страницу, на которую потребитель будет запускать веб-запрос. например https://api.mydomain.com/oauth/access_token?client_id=CONSUMER_KEY&client_secret=CONSUMER_SECRET&oauth_token=OAUTH_TOKEN_RETURNED_ABOVE. Это позволит потребителю обменять oauth_token, возвращенный выше для токена доступа. Я бы просто просто создал случайную уникальную строку и сохранил ее против пользователя для этого конкретного потребителя.

Теперь мой API будет принимать access_token для методов, которые пытаются захватить информацию, специфичную для пользователя, который ее использует.

Я хотел бы знать, правильно ли я понял. Спецификация OAuth 2.0 кажется чрезвычайно тривиальной, если в этом случае. Также почему мы должны обмениваться oauth_token с access_token? У меня есть своя идея, но я был бы признателен, если бы кто-то помог прояснить это.

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

Спасибо

Ответ 1

Фактически протокольные схемы потоков были бы чрезвычайно полезны для визуализации спецификаций, таких как OAuth 2, но есть только некоторые частичные работы. Поскольку я только что реализовал только библиотеку OAuth 2 на стороне клиента, я могу проверить, что вы на правильном пути. Но вот улов:

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

Вот основной процесс проверки подлинности на настольном компьютере (взято из http://developers.gigya.com/020_Developer_Guide/85_REST/OAuth2)

На самом деле это потокная диаграмма с временной шкалой (сверху вниз, взятая из: http://www.ibm.com/developerworks/web/library/wa-oauthsupport/?ca=drs-)

И, наконец, полная процедура: (взято из http://h2anetwork.org/ProjectDocs/DPI/DPI_Framework.html)