Как использовать OpenID или OAuth для внутренней аутентификации первой стороны?

Question

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

Сами приложения будут записаны на разных языках программирования, поэтому подход, ориентированный на язык, обязательный. Мне было предложено использовать OpenID или OAuth или аналогичную инфраструктуру для обработки аутентификации, но я понимаю, что они предназначены для сторонних служб, а не для сторонних служб, которые будут обмениваться данными с нашей внутренней системой. В этом случае у нас может быть служба центрального провайдера со всеми другими приложениями, которые рассматриваются как третьи лица (или полагающиеся стороны).

Вопросы:

1. ли OpenID/OAuth подходит для аутентификации среди первых сторонних сервисов?
2. Если да, то как было бы рекомендовано настроить аутентификацию для этого варианта использования?
3. Разве пользователь не должен предоставлять индивидуальное разрешение каждому серверу сторонних производителей, которое они хотели использовать, так же как им нужно было бы предоставить индивидуальное разрешение любому стороннему серверу? Я думаю, что это нарушит требование наличия единого входа для доступа ко всем услугам первой стороны.
4. Есть ли хорошие примеры сайтов, поддерживающих этот сторонний вариант использования?
5. Что было бы хорошей альтернативной основой для этого использования?

Answer 1

Вам не нужен OAuth для служб единого входа.

Первичное использование/преимущество OAuth, как вы уже знаете, предоставляет доступ к стороннему приложению для доступа/использования вашего ресурса контролируемым образом.

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

Насколько я понимаю, то, что вы можете иметь, это что-то вроде OAuth так, что ваш сервер выделяет токены в приложении. (Я предполагаю, что это полностью внутренняя система, поэтому токены нельзя использовать неправильно).

Поэтому в основном то, что я предлагаю это:

1. Когда приложение пытается получить доступ к первому API он перенаправляется на веб-формы.
2. Пользователь вводит учетные данные и отправляется в БД для проверки.Пусть будет служба, которая генерирует токен для пользователя/приложения
3. Следующий запрос доступа к API будет выполнен с этим токеном - токен однозначно идентифицирует приложение
4. В зависимости от уровня безопасности вам нужно подписать текст используя HMAC и отправляя его как токен, или если его полностью внутреннее просто генерирует уникальный идентификатор для приложения/пользователя и отправляет его другому API
5. При получении токена каждая служба сначала вызывает основной сервер с маркером и внутренними выборками соответствующий идентификатор клиента/пользователя и выполняет требуемую функцию.

Вкратце разделить логин + токен + токен в другом модуле. Все API-интерфейсы должны использовать этот модуль для проверки входа в систему/токена.

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

Answer 2

Oauth поддерживает несколько различных видов потоков. Вы можете использовать поток клиентских кривых из Oauth 2.0, чтобы не просить пользователя предоставлять разрешения для каждого приложения (это предназначено для случаев, когда вы контролируете как сервер, так и приложение, или где вы хотите предварительно авторизовать определенные приложения). Это сообщение хорошо описывает все: http://tatiyants.com/using-oauth-to-protect-internal-rest-api/