В настоящее время я пытаюсь понять, как правильно использовать OpenID Connect и как протекает лог c. Наилучшее описание, которое я нашел, к сожалению, просто говорит об аутентификации пользователя, что поставщик OpenID может свободно использовать любой механизм, который им подходит c. Вот основной источник моего замешательства. Я буду использовать тип предоставления: код авторизации в моих примерах.
Ситуация
CompanyA производит (среди прочего) кучу видео. Эти видео размещены на VideoProvider . Пользователи CompanyA могут получить доступ к этим видео, если у них есть соответствующие права доступа, которые сохранены в видео-списке.
Алиса теперь просматривает домашнюю страницу видео и хочет получить доступ к видео от CompanyA. Это приводит к тому, что поставщику видео требуется информация от CompanyA, к которой видео может получить доступ текущий пользователь (Алиса).
CompanyA предлагает для этого конечную точку OpenID Connect. CompanyA также имеет страницу входа , которая не используется исключительно конечной точкой OpenID Connect.
На данный момент у нас есть:
- RP: VideoProvider
- OP: CompanyA
- IP: страница входа в систему CompanyA
Logi c Flow
RP -> OP
Алиса щелкает на ссылку на видео (в результате чего получить на этот URL). Чтобы разрешить Алисе доступ к этим видео, RP выполняет 302-перенаправление на OP (все еще операция GET):
HTTP/1.1 302 Found
Location: https://www.companya.com/oauth/auth?
response_type=code
&scope=openid%20video-acl
&client_id=ABCDEF
&state=1234567890
&redirect_uri=https%3A%2F%2Fmediaservice.videoprovider.com%2Flogin_cb
OP хранит этот запрос где-нибудь, чтобы впоследствии он мог вызвать его при необходимости.
Теперь начинаются основные источники моей путаницы: как я могу правильно взаимодействовать с IP-адресом безопасным способом и кто показывает пользователю страницу, если он дает согласие на запрос области действия «video-acl». Я напишу то, что, по моему мнению, может быть полезным, но, пожалуйста, исправьте меня, если я допустил какие-либо ошибки.
OP -> IP
OP выполняет 302-перенаправление на IP (все еще GET операция):
HTTP/1.1 302 Found
Location: https://www.companya.com/login_auth?
state=1234567890
&redirect_uri=https%3A%2F%2Fwww.companya.com%2Foauth%2Fauth_cb
IP показывает пользователю обычную страницу входа (с состоянием в скрытом входе). Это может быть имя пользователя / пароль, или в случае действительного сеанса cook ie это может быть запрос на подтверждение, если может использоваться идентифицированная в данный момент учетная запись. Независимо от типа отображаемой страницы, POST отправляется из формы на этой странице в бэкэнд входа в систему.
IP -> OP
IP делает 302 перенаправления на OP (все еще операция POST (?)):
POST /oauth/auth_cb HTTP/1.1
Host: www.companya.com
Content-Type: application/x-www-form-urlencoded
state=1234567890&
account_id=765432
Вопрос: Как я могу быть уверен, что источником этого вызова действительно является поставщик входа в систему, а не какой-то злонамеренный абонент из других мест? Если это 302, как написано выше, этот POST будет go через пользовательский браузер, оставляя там информацию о вызове, таким образом, любой содержащийся секрет будет виден пользователю. Или у меня здесь есть какое-то фундаментальное неправильное понимание?
Теперь ОП может сопоставить через параметр состояния полученный account_id с исходным вызовом. Теперь он может показать запрос на согласие относительно доступа к видео-acl для пользователя (Или это должен был сделать IP вместо этого?) Когда все сказано и сделано, OP где-то сохранил, что с новым кодом (здесь: ABCD3456) RP теперь может запрашивать токен доступа и токен идентификатора для Алисы. и video-acl.
OP -> RP
OP выполняет 302-перенаправление на IP (согласно моему источнику это операция GET, но предыдущий вызов не был POST op, значит, перенаправление все равно будет одним?):
HTTP/1.1 302 Found
Location: https://mediaservice.videoprovider.com/login_cb?
state=1234567890
&code=ABCD3456
RP теперь запрашивает у конечной точки токена токены. Это делается с помощью вызова из-за шторки, который не будет показан пользователю.
RP -> OP
RP делает запрос POST к конечной точке токена с новым httpClient вызов в фоновом режиме (async / await?). Только после того, как это будет полностью решено, пользователю будет показана новая страница со всеми доступными видео.
POST /oauth/token HTTP/1.1
Host: www.companya.com
Content-Type: application/x-www-form-urlencoded
client_id=ABCDEF&
client_secret=ABC123DEF456&
grant_type=authorization_code&
code=ABCD3456&
redirect_uri=https%3A%2F%2Fmediaservice.videoprovider.com%2Flogin_cb
ОП просматривает свои сохраненные данные запроса и знает, что код ABCD3456 приводит к токену идентификатора для Алисы и токену доступа для видео acl. OP генерирует два токена и сохраняет токен доступа (и, возможно, также токен refre sh) со своими ответными данными в своей собственной базе данных.
OP -> RP
OP отправляет OP токены в RP как JSON объект:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "IiwKICJleHAiOiAxMzExMjgxOTcwLAo",
"token_type": "Bearer",
"expires_in": 3600,
"id_token": "ey{...]n0.eyJ{...]SJ9."
}
Правильно ли я понял процедуру? Есть ли какие-либо ошибки в потоке, кроме вопросов, которые я уже отметил?
Если вы хотите использовать несколько примеров кода в своем ответе: я использую C# с. Net Core 3.1 здесь.