Идентификатор сторонних прав RESTful и сторонняя аутентификация

Question

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

Но действительно ли аутентификация по каждому запросу означает, что я вызываю третью сторону (например, Google) много раз, даже если мне от нее ничего не нужно? Например, я использую аутентификацию OpenID, но используемый мной API - это нечто внутреннее (например./Api/tasks/add).

Answer 1

Давайте исправим проблемы понимания в первую очередь. OpenID и OAuth немного отличаются. Существует простой способ запомнить то, что отличается:

• OpenID предназначен для людей. Простой пример: вы хотите пропустить этап бурения регистрации и позволить пользователю повторно использовать существующую учетную запись.
• OAuth предназначен для обслуживания/роботов. Простой пример: вы хотите, чтобы ваш скрипт обращался к внешнему API с некоторыми данными пользователя.

Существует простое объяснение обеспечивается wikipedia:

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

Так I want to use 3rd party authentication ... that user can login easily., вероятно, означает, что вы собираетесь использовать OpenID.

Ответ на ваш вопрос: вам не нужно звонить третьим лицам по любому запросу. Это будет очень неэффективно и медленно. Поставщик OpenID вернет учетные данные пользователя, и вам будет хорошо.

Пожалуйста, убедитесь, что вы определили требования правильно.

Answer 2

OpenID Connect - это механизм аутентификации, написанный поверх OAuth2. Клиент получает токен-носитель, который может отправлять в заголовок авторизации с каждым запросом на сервер ресурсов.

Этот ID-токен является JWT, подписанным поставщиком OpenID. Декодированный маркер выглядит примерно так:

{ 
    "iss": "https://server.example.com", 
    "sub": "24400320", 
    "aud": "s6BhdRkqt3", 
    "exp": 1311281970, 
    "iat": 1311280970 
    } 

Таким образом, можно проверить на сервере ресурсов без необходимости обратитесь к поставщику OpenID. У провайдера OpenID есть конечная точка пользователя, где полагающаяся сторона может получить более подробную информацию о пользователе, которая не включена в токен, например имя и адрес электронной почты.

Answer 3

Я считаю, что ответы Рената Гилманова и Flup должны быть полезны вам, но я постараюсь ответить на вопрос, который был задан здесь.

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

Я буду ссылаться на поставщика OpenID (стороннего) как Google, так как это пример, который вы дали в вопросе. Единственная вещь, которую Authentication будет делать для вас, - это гарантия Google, что человек, делающий этот конкретный запрос, также знает пароль к имени учетной записи Google, которое они вам предоставили.

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

Наиболее распространенным способом было бы передать куки-файлы в браузер сразу, в котором содержится некоторый идентификатор, который вы отслеживаете на сервере, и это подтверждает, что тот, кто передает вам этот файл cookie, также является тем, кто знал пароль для этой учетной записи Google. Другой вариант - отправлять пользовательские заголовки HTTP, что предпочтительнее определенным образом, но сложнее сделать вручную.

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

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