Каков формат openID для входа в систему с помощью образца CTP Oauth Provider

Question

Привет, я только начинаю CTP версии 4, так что я вижу, как я пишу некоторые основные вопросы, когда я обдумываю это. Я хочу создать поставщика услуг, поэтому я смотрю на WCF Oauth2

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

Ура, Крис.

Answer 1

Образец базы данных сервера авторизации OAuth2 просто содержит несколько примеров записей клиента, чтобы образец клиента мог делать запросы.Он имеет таблицу пользователей, которая автоматически заполняется каждым пользователем, который успешно входит в систему, используя свой OpenID.Таким образом, на ваш вопрос, касающийся «формата OpenID», подойдет любой действительный идентификатор OpenID 1.1 / 2.0.

Пример сервера авторизации OAuth2 в этом отношении играет роль проверяющей стороны OpenID, но его функции OpenID не являются основной частью этого примера - существуют другие примеры сайтов OpenID RP, которые демонстрируют больше функциональности в этом отношении.Но поскольку сервер аутентификации OAuth2 и OpenID RP связаны таким образом, поток таков:

1. Пользователь посещает сайт клиента OAuth2 и указывает клиенту, что он может запросить доступ к данным пользователя на ресурсесервер.
2. Клиент перенаправляет пользователя на сервер авторизации, чтобы пользователь мог предоставить разрешение.
3. Сервер авторизации предлагает пользователю войти в систему, если он еще не вошел в систему.
   1. Пользователь входитOpenID
   2. Сервер авторизации перенаправляет пользователя к своему провайдеру OpenID для входа в систему с использованием некоторых учетных данных (имя пользователя / пароль, инфокарта и т. Д.)
   3. Поставщик OpenID перенаправляет пользователя обратно на сервер авторизации.
4. Образец сервера авторизации затем спрашивает пользователя "хотите ли вы поделиться ресурсом [x] с клиентом [y]?"Пользователь подтверждает.
5. Сервер авторизации записывает, что пользователь авторизовал клиента [y] для доступа к [x], чтобы будущие запросы от этого клиента на этот ресурс могли автоматически подтверждаться без вмешательства пользователя.
6. Сервер авторизации перенаправляет пользователя обратно клиенту с предоставлением авторизации.
7. Клиент получает грант вместе с перенаправлением пользователя и использует прямой HTTP-запрос к серверу авторизации для обмена этим предоставлением для маркера доступа (и, возможно, токен обновления).
8. Затем клиент включает токен доступа в HTTP-запросы к серверу ресурсов для доступа к личным данным пользователя.

Надеюсь, это поможет.