Использование собственного API для веб-приложения - Процесс аутентификации с помощью OAuth2

Обзор

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

Итак, мой API должен быть доступен миру: те, у кого есть гостевой доступ (например, пользователи могут загружать, например), а также зарегистрированным пользователям. Поэтому, когда зарегистрированный пользователь загружает, я, очевидно, хочу, чтобы информация пользователя отправлялась вместе с запросом и прикрепляла эту информацию пользователя к загруженному изображению через внешние ключи в моей базе данных.

Аутентификация через OAuth2 - Реализация

Я понял, что OAuth2 - это способ пойти, когда дело доходит до аутентификации API, поэтому я собираюсь реализовать это, но я действительно изо всех сил пытаюсь оборачивать голову тем, как справляться с моей ситуацией. Я подумал об использовании гранта client credentials и создании только одного набора учетных данных для моего веб-приложения и отправки ему запросов в API с помощью client secret для получения токена доступа и предоставления пользователям возможности вещи. Сам процесс регистрации пользователя будет обрабатываться с помощью этого гранта.

Но как насчет регистрации и регистрации пользователя? Как мне теперь обрабатывать аутентификацию? Будет ли это требовать от другого гранта? Я думал о том, чтобы сделать некоторый процесс авторизации во время входа пользователя, чтобы создать новый токен доступа. Является ли этот подход неправильным?

Мне нужна помощь с

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

ОТВЕТЫ

Ответ 1

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

Итак, для стартеров грант клиентских учетных данных не для вас. Если мы посмотрим на спецификацию OAuth2, грант учетных данных клиента для

когда область полномочий    ограниченный защищенными ресурсами под контролем клиента... когда клиент действует от своего имени

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

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

Как работает регистрация пользователя? Простой, вы отправляете некоторый пользовательский объект, например

name: jim beam
username: jimb
password: correct horse battery staple

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

Надеюсь, это больше того, что вы ищете.

Ответ 2

Ваш подход кажется работоспособным.

Oauth2 имеет 4 основные части:

  • Сервер ресурсов (ваш API)
  • Владелец ресурса (конечный пользователь, имеющий данные на сервере ресурсов)
  • Сервер авторизации (получает токены авторизации и выпуска)
  • Клиент (ваше веб-приложение - и будущие приложения)

Имейте в виду, что Client Credentials grant, маркер, который вы выпустили, вероятно, не будет иметь никакого контекста пользователя. Поэтому, если ваши конечные точки API полагаются на идентификатор пользователя/владельца ресурса, содержащийся в токене, тогда вам нужно будет скопировать код для этого типа токена.

Если вам нужен токен, чтобы иметь некоторый контекст владельца ресурса для вашего API, и ваше веб-приложение оказывается вашим поставщиком удостоверений, тогда вы можете использовать пароль владельца ресурса, который даст вам токен и обновить токен в контексте владельца/пользователя ресурса.

Предоставление Authorization code гарантирует, что ваши будущие пользователи API будут веб-приложениями (то есть запускаются на серверах). Если вы планируете использовать мобильные/родные приложения для использования вашего API, вам следует рассмотреть возможность предоставления Неявно Гранта на вашем сервере авторизации.

Если ваш API не имеет конечных пользователей, и каждый клиент имеет различный доступ к API в зависимости от того, что это такое, то вы можете использовать грант клиентских полномочий и использовать scopes, чтобы ограничить доступ к API.

ИЗМЕНИТЬ

Итак, мой API должен быть доступен миру с гостевым доступом (не зарегистрированные пользователи могут загружать, например) и зарегистрированным пользователям. Так когда зарегистрированный пользователь загружает, я, очевидно, хочу, чтобы пользователь был отправлен вместе с запросом и прикрепить этого пользователя к загруженному изображению

Для достижения этой цели конечная точка загрузки API может обрабатывать маркеры маркера Oauth2.0, но не зависеть от них. например конечная точка может использоваться кем угодно, а те, кто предоставляет токен доступа в заголовках, будут иметь свою загрузку, связанную со своим пользовательским контекстом, полученным API изнутри токена. Затем вы можете сделать другие конечные точки зависимыми от маркера.

ИЗМЕНИТЬ на основе комментариев

сам процесс регистрации будет использовать грант учетных данных клиента, правильно?

Я не думаю, что сам процесс регистрации должен быть ресурсом, защищенным Oauth. Идеальная регистрация должна выполняться вашим провайдером удостоверения (например, google, facebook или собственной собственной пользовательской базой данных). Одна из плюсов в Oauth2.0 заключается в том, что она устраняет необходимость использования API-интерфейсов для работы с пользователями.

Ответ 3

Вам не требуется oauth для аутентификации вашего собственного API.

OAuth2 полезен, если вы хотите, чтобы другое приложение обращалось к вашему API.

Позвольте мне немного пояснить, как работает OAuth2:

  • Клиент (приложение) хочет использовать ваш API, чтобы предоставить ему учетные данные клиента (client_token и client_secret). И вы установите в своей базе данных набор мест перенаправления, которые клиент может использовать.
  • Клиенту требуется авторизация пользователя, чтобы он использовал ваш API в имени пользователя. Таким образом, клиент отправляет пользователя на URL-адрес вашего сайта (с клиентом_token, областью, в которой клиент нуждается [вы определяете значение различных областей применения], urid перенаправления и response_type [oauth2 определяет другой параметр response_type, но позволяет сосредоточиться на "коде" "])
  • Пользователь регистрируется на вашем сайте и принимает доступ к клиенту для вашего API от имени пользователя. Когда пользователь примет это, вы создадите грант (грант содержит информацию о пользователе, запрошенные учетные данные [область] и клиент, который может "требовать" предоставленный доступ).
  • Затем пользователь перенаправляется на адрес redirect_uri, который запросил клиент (когда клиент отправил пользователя на ваш сайт auth), и в параметрах URL-адреса вы укажете код предоставления (это просто идентификатор).
  • На этом этапе клиент сделает запрос к вашему API, предоставив код предоставления, свой собственный client_token, его client_secret и grant_type (authorization_code), и он ответит на следующий ответ: authorization_token, refresh_token, token_type ( для этого случая, Bearer), expires_in (время истечения в секундах) и область действия.
  • После этого клиент сможет запросить ваш API от имени пользователя, используя access_token, назначенный до истечения срока действия токена. Как только токен истечет, клиент должен будет запросить новый access_token, используя refresh_token (вместо кода авторизации).