Начал со статьи https://habrahabr.ru/company/mailru/blog/115163/

Как я понял в этой схеме есть несколько сущностей и я не уверен, что я правильно понимаю кто есть кто.
-моё приложение
-ресурс сервер
-сервер авторизации

на просторах интернета нашёл такую картинку:



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

А что если моему приложению по сути никакие ресурсы не нужны? мне просто достаточно, что юзер имеет учетную запись на авторизационном сервере(кнопочки на сайтах формата зайти через google/vk. Скажем stackoverflow вообще не имеет кнопки зарегистрироваться)?Каждый клиентский запрос должен содержать токен и мы каждый раз шлём запрос на авторизационный сервер, который должен содержать какой-то сервис для проверки валидности токена?

ещё вот эту схему с редиректами вообще не понял.



Объясните пожалуйста основные концепции. Я явно что-то неправильно понимаю.

Petro123,

обычно сначала теория, потом практика)

Но вообще я начал уже смотреть на http://www.baeldung.com/sso-spring-security-oauth2

Petro123questionerобычно сначала теория, потом практика)я тебе и сказал, что это не правда.
...
Вообще, в sso как вариант, в фильтре перед ЛЮБЫМ get запросом идет на сторонний сервис запрос. Ну а токен это понятно. Как без него.

а вы не путате sso и oauth2?

P.S. я путаю

Petro123,

я вот взял следующий пример, который у меня запустился:

https://github.com/eugenp/tutorials/tree/master/spring-security-sso

Не понятно как именно это работает. Какие-то редиректы туда-сюда.


зашёл на сайт:

http://localhost:8082/ui/

нажал на кнопку Login

и вот уже что в нетворке(preserve log включен):



ссылка на которую я нажимаю это





ок, браузер пытается зайти на http://localhost:8082/ui/securedPage

Вот дальше не понимаю что происходит. Почему она возвращает 302? где это настроено?

Как приложение понимает, что я не залогинен?

Petro123questionerА что если моему приложению по сути никакие ресурсы не нужны?
ресуры это все урлы в web.xml
Т.е. все странички в твоём веб проекте.
Поэтому вопрос непонятен.


Как stackoverflow. Ему мой профиль гугл вообще не сдался.

Petro123questionerКак stackoverflow.
а он тут причём вообще?

Я так понимаю это пример SSO.
я про сайт если что

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


Petro123questioner,
у него нет авторизации, поэтому я не понял причём тут он.
Ближе к практике!

Я понимаю на уровне слов, что авторизация это предоставление прав. А как вы поняли, что у SO нет авторизации?

Petro123questionerА как вы поняли, что у SO нет авторизации?
нигде не видел чтобы через него запускали на сайт)))
Повторяю вопрос - почему не взять простые примеры?

Так там вроде кода кот наплакал? есть примеры проще?

maytonquestionerпропущено...


Так там вроде кода кот наплакал? есть примеры проще?
Информационная безопасность - это хитрая штука. Ее протколы
не объясняют мотивацию того или иного действия. И вообще
чтобы их понимать - нужно иметь некое "седое" зрение в области
разработки проектов под нагрузкой. А пока этого зрения
у тебя нет - тебе все время будет казаться что некоторые
шаги не нужны и их вообще можно выкинуть из проекта.
И это нормально. Это просто говорит о том что ты пока
не видишь причин для использования Oauth. Не нужен
вобщем-то он тебе. Такие вот дела.

Может лучше возьмешь тему попроще?

Да ладно Вам. Рокет саенса в этой теме точно нет

Petro123questionerДа ладно Вам. Рокет саенса в этой теме точно нетну дак сделай вход через Одноклассники и узбагойся.

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

Petro123questioner,
Основной метод развития программиста - самообучение.
Хотя бы поиск набери.

Ну конечно я искал. Вообще мне интересно сделать именно в разрезе спринга. То, что я нашёл выглядит как самый простой пример. Поэтому моя просьба сводится к тому, чтобы мне помогли в нём разобраться

scfПочему бы не начать с азов?
https://tools.ietf.org/html/rfc6749

Достаточно хорошо и понятно написано.


автор
The abstract OAuth 2.0 flow illustrated in Figure 1 describes the
interaction between the four roles and includes the following steps:

(A) The client requests authorization from the resource owner. The
authorization request can be made directly to the resource owner
(as shown), or preferably indirectly via the authorization
server as an intermediary.

(B) The client receives an authorization grant, which is a
credential representing the resource owner's authorization,
expressed using one of four grant types defined in this
specification or using an extension grant type. The
authorization grant type depends on the method used by the
client to request authorization and the types supported by the
authorization server.

(C) The client requests an access token by authenticating with the
authorization server and presenting the authorization grant.

(D) The authorization server authenticates the client and validates
the authorization grant, and if valid, issues an access token.
(E) The client requests the protected resource from the resource
server and authenticates by presenting the access token.

(F) The resource server validates the access token, and if valid,
serves the request.

The preferred method for the client to obtain an authorization grant
from the resource owner (depicted in steps (A) and (B)) is to use the
authorization server as an intermediary, which is illustrated in
Figure 3 in Section 4.1.


Помогайте разбираться.

Ресурс оунер это я.
Клиент это моя программа.
Ресурс сервер это гугл драйв с моими фоточками.
Авторизейшен сервер это гугл. гугл аккаунтс какой-нить


я должен дать приложению какой-то авторизейшен грант. Либо напрямую либо как-то непрямо через авторизейшен сервер. Не очень понятно. И непонятно что такое грант. В доке про грант пишут

авторAn authorization grant is a credential representing the resource
owner's authorization (to access its protected resources) used by the
client to obtain an access token. This specification defines four
grant types -- authorization code, implicit, resource owner password
credentials, and client credentials -- as well as an extensibility
mechanism for defining additional types.

Отсюда делаю вывод, что эта какая-то херь нужная для получения токена, только непонятно зачем. Дал приложению грант. Оно идёт с этим грантов на авторизационный сервер. Сервер по гранту даёт ему токен. При доступе к ресурасам вставляем токен в любой запрос и сервер сможет провалидировать нас.




Вот что написано на Figure 3 in Section 4.1.


авторThe authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.




авторThe flow illustrated in Figure 3 includes the following steps:

(A) The client initiates the flow by directing the resource owner's
user-agent to the authorization endpoint. The client includes
its client identifier, requested scope, local state, and a
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).

(B) The authorization server authenticates the resource owner (via
the user-agent) and establishes whether the resource owner
grants or denies the client's access request.

(C) Assuming the resource owner grants access, the authorization
server redirects the user-agent back to the client using the
redirection URI provided earlier (in the request or during
client registration). The redirection URI includes an
authorization code and any local state provided by the client
earlier.

(D) The client requests an access token from the authorization
server's token endpoint by including the authorization code
received in the previous step. When making the request, the
client authenticates with the authorization server. The client
includes the redirection URI used to obtain the authorization
code for verification.

(E) The authorization server authenticates the client, validates the
authorization code, and ensures that the redirection URI
received matches the URI used to redirect the client in
step (C). If valid, the authorization server responds back with
an access token and, optionally, a refresh token.


A- приложение инициирует авторизационное флоу направляя браузер ресурс оунера на сервер авторизации.
Приложение предоставляет ресурс серверу
client identifier - непонятно что
requested scope- непонятно что
local state - непонятно что
redirection URI to which the authorization server will send the
user-agent back once access is granted (or denied).

B - я ввожу логин и пароль и авторизационый сервер авторизует ресур оунера(меня) через браузер

С - бразуер редиректит меня по урлу, который был предоставлен в пункте А и добавляет к нему какие-то неясные параметры (authorization code and any local state)

D - Зная authorization code приложение делает запрос к ресурс серверу для получения токена. В урл надо добавить redirection URI чтобы авторизационый сервер смог вернуть результат авторизации

E - авторизационный сервер анализирует authorization code(смотрит выдавал ли он такой кому-нить?) проверяет, что redirection URI который он получил совпадает с тем что был использован в том пункте когда авт. сервер редиректил при выдаче authorization code(видимо выполняя пункт C он хранит маппинг урла на authorization code). В результате сервер шлёт ответ приложению в котором содержится токен.


Если клиенту понадобится что-то от ресурс сервера - надо в запрос добавлять этот токен.

Всё правильно?

Ответьте плиз на вопросы внутри текста.

scf,

scf.к. список разрешенных редиректов для клиента фиксирован, т.е. левый сайт не получит токены
Кто их фиксирует? где это делается тут
https://github.com/eugenp/tutorials/tree/master/spring-security-sso

авторAS просит RO залогиниться, а потом подтвердить выдачу прав для клиента

залогиниться и тем самым подтвердить? я просто после ввода логина и пароля уже залогинен на сайте если взять пример выше и никто меня не спрашивает о явной выдаче прав.

в результате логина клиент получает код.

по коду клиент уже без участия браузер выполняет запрос и получает токен.

а почему код не секретен?

вот я нашёл кусок кода на сервере который получает запрос на токен и в запросе такие вот параметры:



По сути только код. Или вы имеете ввиду, что однажды его использовав ничего не получится использовать его второй раз?

Коды даются по логину и паролю, которых никто не знает.

Правильно я понимаю, что если мы получили код, но по какой-то причине не сделали запрос на токен, то злоумышленник сп#здивший этот код сможет получить токен если угадает grant_type и redirect_uri ?

Sergunka,

авторThe purpose of the workflow is that the access token and client secret will never be exposed to the resource owner

Цель воркфлоу заключается в том, что access token и client secret(логин и пароль?) никогда не будут доступны владельцу ресурса.

Чего-то не очень понятно. ресурс оунер это пользователь. В чем суть от него скрывать access token и client secret?

Sergunka,

Authorization Code Grant - понятно
приложение редиректит меня на авторизационный сервер, где я ввожу креды. В ответ мой браузер получает Grant Code. Этот код получает приложение и в обмен на него оно получает от авторизационного сервера access токен

Implicit Grant

не понял, объясните плиз

Кто есть кто на этой картинке в термина объявленных в начале статьи.
Что за сообщения шлются?(что за client id?)

Resource Owner Password Credentials Grant

Просто отдаём приложению(клиенту) логин и пароль. Оно уже по логину и паролю получает токен.
Выглядит как-то глупо.

Client Credentials Grant

Выглядит так же как и предыдущее(Resource Owner Password Credentials Grant) только разница в том, что даём не логин и пароль, а какой-то Authorization . Не понятно откуда он берётся.


Extension Grants

Это требует интеграции с неким внешним сервисом?
google authenticator?
двухфакторная аутентификация?

Некий сервис интегрирован например с Okta.

Чтобы зайти в приложение мне надо ввести логин и пароль на сайте, потом меня редиректит на Okta где я ещё должен ввести код из google authenticator и после успешного ввода меня вернёт на основной сайт.
Только я забыл по какому коду я регистрируюсь в гугл аутентификаторе

SergunkaquestionerSergunka,

пропущено...


Цель воркфлоу заключается в том, что access token и client secret(логин и пароль?) никогда не будут доступны владельцу ресурса.

Чего-то не очень понятно. ресурс оунер это пользователь. В чем суть от него скрывать access token и client secret?

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

Если я правильно понимаю, то обычно всё наоборот.

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

Sergunka Поймите меня правильно я очень благодарен, что Вы читаете мой блог... но по Вашему вопросу про имя клиента Вы полностью не понимаете концепцию Аоз 2 протокола. Последуйте моему совету и просто тупо используйте PostMan, чтоб через руки понять как все происходит
И куда мне отправлять запросы прикажете?
К тому же у вас не написано как получить то, что отправлять)

Sergunka,

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

я тут исхожу из ваших же терминов
авторresource owner:
An entity grants access to a protected resource. In most cases, the owner is a person and it is referred to as a user
resource server:
A server that runs your application and handles the protected resources
client:
The client makes the protected resource requests on behalf of the resource owner using its authorization access workflows
authorization server:
The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Какое-то блуждание в трёх соснах. Явно тут никакая не высшая математика

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

Так Вася что и клиент и пользователь?

Как соотносятся понятия Jwt и oauth2?