Начал со статьи 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). В результате сервер шлёт ответ приложению в котором содержится токен.


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

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

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