Либо вы знаете, для какого API требуется аутентификация, поэтому, если у вас нигде нет этого токена, вы должны перенаправить пользователя на oauth-сервер. Как только этот перенаправит обратно на ваше приложение, вы найдете токен в URL (параметр, если у меня хорошая память). Этот токен необходимо сохранить в памяти для последующего использования или в базе данных вашего приложения (стандартная функция браузера). Затем вы можете позвонить в API, используя этот токен, который вы сохранили.
Если вы не знаете, для какого API требуется аутентификация или если срок действия вашего токена истек, вы все равно звоните в API и получаете ошибку 403 (не авторизовано). Любая ошибка 403 должна привести к тому, что клиентское приложение решит перенаправить пользователя на портале аутентификации для получения нового токена.
Поскольку вы используете поток кода, я полагаю, вы должны разработать реактивное, угловое или любое спа-приложение. Поэтому я советую вам использовать oidc-клиент. Это библиотека javascript, разработанная теми же парнями, которые разработали идентификационный сервер. Это упрощает разработку клиента при работе с аутентификацией oauth.
Вот более подробное описание процесса и проверки / переменных, которые сделаны / использованы:
- Клиентское приложение (javascript / html5) выполняет вызов на сервер ресурсов без какого-либо токена в заголовке http-запроса аутентификации
- Сервер ресурсов (ваш сервер API) пытается получить токен в заголовке
- не существует. Это означает, что запрос не аутентифицирован.
- Сервер ресурсов возвращает клиенту ошибку 403 перед тем, как даже выполнить какой-либо вызов контроллера или даже проверки авторизации (роли и т. Д.)
- Клиент ловит эту ошибку 403, а затем знает, что токен необходим для этого вызова.
- Клиент сохраняет URL-адрес запроса, который не прошел, и его сообщение (если применимо) в приложении db
- Клиент перенаправляет браузер на URL-адрес сервера аутентификации, передавая идентификатор клиента (идентификатор приложения javascript / html5 для сервера аутентификации), область действия (какой набор ресурсов должен использоваться этим клиентским приложением в контекст этого запроса аутентификации) и URL-адрес, по которому сервер аутентификации должен перенаправить пользователя обратно после его аутентификации.
- Сервер аутентификации запрашивает у пользователей аутентификацию (любым способом, который вы можете себе представить, но чаще всего, запрашивая у него логин и пароль)
- если пользователь распознается сервером аутентификации (пароль, который совпадает с логином), этот проверит, будет ли возвращаемый URL-адрес (URL-адрес, переданный клиентским приложением, использоваться для перенаправления пользователя справа). после проверки подлинности) находится в списке предоставленных URL-адресов возврата для этого клиентского приложения ( RedirectUris, о котором вы задаетесь вопросом ). Суть этого заключается в том, чтобы гарантировать, что выданный токен не будет передан в незарегистрированное приложение (например, внешнее приложение javascript / html5, размещенное в Китае, которое может найти способ высосать некоторые данные с вашего сервера API, о которых может знать только ваш пользователь. и отправка на русский api-сервер, даже если пользователь этого не заметил)
- он также проверяет, может ли это клиентское приложение (а не пользователь ... здесь убедиться, что конкретное клиентское приложение javascript / html5 может получить доступ к набору ресурсов) может использовать запрашиваемую область.
- если проверки в порядке, сервер аутентификации выдает access_token, подписывая его своим закрытым ключом.
- сервер аутентификации перенаправляет пользователя на первоначально переданный URL-адрес возврата, задав в качестве параметра access_token в URL-адресе.
- клиентское приложение получает этот параметр и сохраняет его где угодно (где угодно, но чаще всего в базе данных приложения и в памяти)
- клиентское приложение получает URL-адрес, сохраненный для повторного вызова, но на этот раз с access_token в заголовке аутентификации
- сервер API (или сервер ресурсов) снова получает запрос http
- наконец находит access_token и проверяет, действительно ли он был выдан сервером аутентификации (используя его открытый ключ), так как это единственный уровень, которому доверяют выдавать токен.
- тогда он может доверять тому, что находится в токене: идентификатор пользователя, который упоминается внутри, области (набор функций), к которым разрешен доступ, и т. Д ...
- затем он вызывает контроллер и возвращает ответ. Если срок действия токена истек (простая дата, указанная в токене), он не обращается к контроллеру и не возвращает 403.
К вашему сведению, всему, что находится в токене, можно доверять, если его подпись уже была сделана сервером аутентификации. Эта система предотвращает нарушение среднего уровня безопасности. Значение: парень, который получил токен, следя за сетевой активностью, изменяет содержимое этого токена, чтобы он мог делать любые вызовы на ваш сервер API. Любые изменения, внесенные в этот токен, будут обнаружены, поскольку подпись (своего рода зашифрованный хэш) больше не будет соответствовать новому содержимому. И эта подпись, если каждый может проверить ее в мире с помощью открытого ключа, только один уровень может выдать ее со своим закрытым ключом: сервер аутентификации.
Я пытался сделать его как можно более полным и все же понятным для новичка в том, что вы утверждаете. Надеюсь, это поможет.