Пользовательская конечная точка OAuth2 /oauth/authorize

Я действительно стараюсь, чтобы мой бэкенд RESTful оставался в блаженном неведении обо всем, что связано с HTML. Я хотел бы, чтобы он говорил только JSON с моим внешним интерфейсом HTML/CSS/JS и другими подключающимися клиентами. OAuth2 предоставляет AuthorizationEndpoint сервис /oauth/authorize. По умолчанию страница утверждения пользователем предназначена для HTML-результата, сгенерированного ModelAndView.

Я бы предпочел, чтобы мой внешний интерфейс HTML/CSS/JS обрабатывал отображение страницы подтверждения (и, возможно, логин), а затем отправлял одобрение пользователя в /oauth/authorize. Результатом POST-запроса /oauth/authorize будет результат JSON, содержащий токен и URL-адрес для перенаправления. Затем интерфейсный код будет обрабатывать перенаправление браузера обратно клиенту. В остальном процесс будет проходить в обычном режиме.

Я думаю об этом неправильно? Есть ли какие-либо проблемы безопасности, которые я не принимаю во внимание?

Спасибо!


spring-security-oauth2
person Michael Ressler    schedule 21.01.2015    source источник
comment
При реализации этого я обнаружил, что дублирую большую часть кода AuthorizationEndpoint. Хотя я бы хотел создать подкласс класса AuthorizationEndpoint, похоже, что AuthorizationServerEndpointsConfigurer жестко кодирует ссылку на класс AuthorizationEndpoint. Возможность подключиться к этому authorizationEndpoint() и изменить созданный класс значительно облегчит эту задачу. Есть ли механизм, который я не вижу, чтобы сделать это?   -  person Michael Ressler    schedule 22.01.2015
comment
Кажется, что кратчайший путь к тому, чтобы сделать такую ​​задачу простой, — это попросить AuthorizationServerEndpointsConfigurer предоставить AuthorizationEndpoint. Таким образом, я мог предоставить свою собственную реализацию и по-прежнему подключаться ко всем существующим механизмам. Прямо сейчас я нахожусь в мире копирования/вставки.   -  person Michael Ressler    schedule 22.01.2015
comment
Учитывая, что я пока не могу предоставить замену AuthorizationEndpoint для AuthorizationServerEndpointsConfigurer, я просто хочу предоставить сконфигурированные объекты (TokenGranter, ClientDetailsService, AuthorizationCodeServices, OAuth2RequestFactory, OAuth2RequestValidator и UserApprovalHandler) как bean-компоненты. Если я могу представить их как bean-компоненты, то я могу позволить фреймворку @Autowire использовать их в моей замене AuthorizationEndpoint. Есть какие-нибудь мысли по этому поводу?   -  person Michael Ressler    schedule 22.01.2015

Ответы (2)


arrow_upward
1
arrow_downward

Я думаю, вы идете в неправильном направлении. Login и Approval страницы должны быть предоставлены сервером авторизации и с использованием стандартов HTTP (например: перенаправление с использованием заголовка Location).

Если вы хотите сделать что-то своими руками, рекомендуем тип гранта Resource Owner Password. Но это может не подходить для чистого веб-приложения на стороне клиента. Потому что он не может (или с трудом) обеспечить безопасность secret key!

У меня также есть приложение, похожее на ваше, написанное с помощью AngularJS и использующее implicit поток. Мое приложение полностью использует RESTful для общения с сервером. За исключением входа/авторизации приложения, это делается другим веб-приложением (Spring MVC — по умолчанию Sparkl) в другом домене.

person Thanh Nguyen Van    schedule 22.01.2015
comment
Почему это должно быть предоставлено сервером аутентификации? Я не читал этого в спецификации, и это похоже на извращение моего прекрасного сервера REST/JSON. Я опубликую решение, которое я придумал для этого, как только убедюсь, что оно работает так, как я ожидаю. Но он использует pathMapping() для изменения oauth/confirm_access на redirect:(url). Я думаю, что это решение, которое я искал в конце концов. - person Michael Ressler; 23.01.2015
comment
Потому что только trusted client может принять учетные данные пользователя и использовать их для обмена на access token. Как вы можете доказать, что вашему приложению доверяют без client_secret? - person Thanh Nguyen Van; 23.01.2015

arrow_upward
0
arrow_downward

Да, у меня была аналогичная проблема, я выполняю аутентификацию на странице обратной передачи клиента, а затем, только позже, я запускаю пользователя в SPA, поэтому, поскольку пользователь уже авторизован, я просто хочу преобразовать его файл cookie в токен. . Я закончил тем, что написал что-то вроде этого, которое в основном обходит большинство вещей oauth. Я думаю, что это будет работать только в том случае, если у пользователя есть действительный файл cookie аутентификации .NET в запросе, поэтому он должен быть как минимум таким же безопасным, верно?

    [AllowAnonymous]
    public ActionResult GetToken()
    {
        if (!User.Identity.IsAuthenticated)
        {
            Response.StatusCode = 403;
            return Json(new {message = "Forbidden - user not logged in."}, JsonRequestBehavior.AllowGet);
        }

        var claims = new ClaimsPrincipal(User).Claims.ToArray();
        var identity = new ClaimsIdentity(claims, "Bearer");
        AuthenticationManager.SignIn(identity);
        var ticket = new AuthenticationTicket(identity, new AuthenticationProperties());
        var token = Startup.OAuthOptions.AccessTokenFormat.Protect(ticket);
        return Json(new { token }, JsonRequestBehavior.AllowGet);
    }
person keithl8041    schedule 10.09.2015