Рекомендуемая аутентификация UX в AngularJS SPA с собственными и внешними (Google, FB...) профилями

Я разрабатываю Asp.net MVC + Web API + AngularJS SPA. Я хотел бы иметь несколько типов регистрации/аутентификации:

поставщик собственного профиля
внешние поставщики, т.е. Google, FB и т.д.

Возможные сценарии

Поскольку у меня есть SPA, было бы лучше, если бы я мог держать моего пользователя на моей странице, в то время как внешний (или внутренний, если на то пошло) будет иметь место. Я бы показал модальный слой с определенным загруженным содержимым (возможно, даже внутри iframe). Можно ли это сделать? Примеры в Интернете?
Возможность входа/регистрации реализована как обычный Asp.net MVC полностраничный контроллер перезагрузки/просмотров, а затем перенаправляет обратно в мой SPA, когда это будет успешным. Также перенаправляйтесь к внешнему провайдеру, если пользователи хотят аутентифицироваться/регистрироваться с использованием внешнего поставщика.
Любая другая возможность?

Вопросы

Как вы делали этот похожий сценарий в своем SPA или как вы порекомендовали бы его сделать?
Должен ли я использовать определенные шаблоны проверки, связанные с этим, например, предоставить мою внутреннюю аутентификацию/регистрацию, аналогичную внешней, поэтому SAP всегда будет вести себя одинаково.
Мне также придется аутентифицировать вызовы веб-API впоследствии после того, как пользователь проверит себя в SPA. Любые указания по этому поводу?

Ответ 1

Я могу только прокомментировать мой собственный опыт, возможно, это полезно. Мы используем тот же стек, что и вы, Asp.net MVC + Web API + AngularJS. Мы используем MVC на стороне сервера для аутентификации (Microsoft.AspNet.Identity), поскольку на данном этапе мы не публикуем публичный API, и единственным потребителем API будет наш SPA, который отлично работает с минимальными затратами усилий.

Это также позволяет нам установить службу UserContext Angular на сервере после входа в систему, который может быть передан через ваше приложение Angular, ребята DoubleClick Manager Google используют некоторые преимущества этого подхода во время ng -conf презентация. Поскольку Web Api поддерживает идентификацию Asp.Net, аутентификация и авторизация беспрепятственно работают между MVC и Web Api.

Подводя итог основным плюсам и минусам:

Плюсы:

Очень легко и быстро реализовать.
Работает через MVC и Web Api.
Ключ-код не должен касаться кода аутентификации.
Установить UserContext Angular услугу на стороне сервера один раз во время входа в систему, легко распределяемый по всему SPA с помощью Angular DI. См. презентация, как указано выше.
Интегрируется с внешними поставщиками так же легко, как и с любым обычным MVC-приложением.

Минусы:

Поскольку браузер не отправляет хэш-часть URL-адреса на сервер, возвращаемый URL-адрес при входе в систему всегда будет корнем вашего SPA. Например. предположим, что ваш корневой центр SPA/приложение, и вы пытаетесь получить доступ к /app #/client, когда вы не прошли аутентификацию, вы будете перенаправлены на страницу входа в систему, но URL-адрес возврата будет /app, а не /app #/client, как сервер не имеет возможности узнать хэш-часть URL-адреса, поскольку браузер никогда не отправляет его.
Не поддерживается дизайн, если вы планируете сделать свой веб-Api доступным вне вашего SPA. Представьте консольное приложение, пытающееся подключиться к вашему API?

Таким образом, представление MVC, которое мы используем для загрузки нашего SPA, защищено с помощью [Authorize], а также с нашими методами Web Api. Внутри MVC-представления мы также инициализируем нашу службу UserContext Angular, используя Razor, чтобы вводить все пользовательские свойства, которые мы хотим открыть. После того, как SPA загружается через единый вид Razor, все остальное обрабатывается через Angular.

Ответ 2

Мы использовали то, что описано выше Beyers, и оно хорошо работает для большинства приложений, и я часто его использую.

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

Обычный жизненный цикл:

Пользователь отправляется на сайт www.server.com
Сервер отправляет index.html
Клиент запрашивает информацию о мини-активах (.js,.css. и т.д.).
Angular load - директива удаляет класс загрузки из тела (раскрывая раздел входа в систему)
- Angular LoginCtrl делает попытку автолога. (Вход и автолог в службе Angular).
- Сервер возвращает HTTP 401
Экран входа в систему остается видимым.
Пользователь успешно входит в систему (сервер дает браузеру cookie authToken, Angular не знает и не заботится)
Angular устанавливает некоторые переменные isAuthenticated в BodyCtrl и LoginCtrl
Раздел входа получает класс .hidden, а контент получает класс .visible(вставляйте ng-hide/show animations для удовольствия)
Пользователь начинает заполнять форму, но принимает обязательный 30-минутный телефонный звонок от родственника.
Сервер истек свою сессию 10 минут назад
Пользователь заканчивает и отправляет форму, но сервер возвращает неавторизованный (401)
http-auth-interceptor перехватывает 401 с сервера, кэширует вызов отправки и публикует событие "login-required".
BodyCtrl прослушивает и устанавливает isAuthenticated = false, а затем ng-class и ng-show/hide работают в разделах входа и содержимого.
Пользователь повторно подписывается и публикуется событие с подтверждением входа в систему.
http-auth-interceptor публикует кешированный вызов.
Пользователь счастлив.
(раздел контента также может отображать некоторые общедоступные представления, так как наш api для отдыха имеет некоторые маршруты, которые становятся общедоступными - отображение общедоступных представлений обрабатывается простой функцией, аналогичной isAuthenticated).

Angular Структура Ctrl:

index.html

<body>
    <!-- I am a fullscreen login element, z-index=2000-->
    <div data-ng-controller="LoginCtrl" data-ng-hide="isAuthenticated()"</div>
    <div data-ng-controller="ContentCtrl">
        <!-- fullscreen class has a z-index=2001 -->
        <section data-ng-view data-ng-class="{fullscreen: isViewPublic()}"></section>
        <!-- header and nav go here -->
    </div>
</body>

Мы могли бы немного поработать над тем, как показывать общедоступные представления/маршруты, но вы получаете эту идею. У нас есть только несколько общедоступных маршрутов, и они в основном предназначены для регистрации, сбрасывания пароля и т.д.

Отказ от ответственности. Мне еще предстоит интегрировать службы oauth/external authentication. Надеемся, что эта настройка по-прежнему будет содержать воду.

Любая критика этого процесса приветствуется.

Ответ 3

Ни в коем случае не знаком с бэкэндами Microsoft, но все же попробую:-):

Хорошие ресурсы по тому, как сделать аутентификацию/авторизацию в Angular на основе SPA:

https://github.com/fnakstad/angular-client-side-auth
live demo: http://angular-client-side-auth.herokuapp.com/login
- По вашему запросу существует два метода аутентификации:
  - собственный профиль
  - внешние провайдеры.
    Он перенаправляет на веб-сайт провайдера: -/
- NodeJS на бэкэнд
Хорошее обсуждение ng-conf о том, как авторизация выполняется в приложении Google Doubleclick Manager: http://www.youtube.com/watch?v=62RvRQuMVyg&t=2m29s
Это не совсем то, что вы хотите (аутентификация), но решение начинает атаковать фазу аутентификации. Кроме того, это может быть полезно позже, и подход, который представляет Идо, кажется действительно здоровым.
Слайды: https://docs.google.com/file/d/0B4F6Csor-S1cNThqekp4NUZCSmc/edit
И последнее, но не менее важное: Освоение разработки веб-приложений с помощью AngularJS. Блестящая книга Angular Пауэла Козловского и Пете Бэкона Дарвина.
В нем есть целая глава или две посвященные автору. В нем представлены некоторые сложные решения, такие как перехватчики и повторные сеансы. Но даже если вы не будете использовать подходы из книги напрямую, эти главы по-прежнему являются обязательными, поскольку они могут дать вам вдохновение для разработки ваших собственных решений.

Примечание - http-auth-interceptor: Как уже упоминалось в книге, решение securityInterceptor было первоначально изобретено Witold Szczerba. См. сообщение в блоге.
http-auth-interceptor код, упомянутый @CorySilva, на самом деле является образцом кода для понятий, объясненных в сообщении.

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

btw2: Если кто-то не считает себя экспертом Angular, вся книга, безусловно, обязательно должна быть прочитана и дополнена после чтения Руководство

Что касается создания страницы входа в ASP с ASP, я предлагаю использовать ASP только как бэкэнд и промежуточное программное обеспечение, а всего рисовать приложение с помощью Angular.
Вы можете начать с вашего подхода и перейти к чистому Angular SPA, если он начнет требовать все больше и больше сумасшедших хаков, чтобы технологии хорошо сочетались.
Но я могу ошибаться, и этот конкретный случай не требует применения каких-либо хаков.