AngularJS + OpenID Connect

[shadow7256]

Уважаемые,

Имеем SPA приложение, написано на AngularJS (важно. На старинном AngularJS). Кастомер хочет, чтобы это приложение использовало Single Sign On и в качестве Identity Provider использовало Okta. В самой Окте нам сказали, что для этого нужно использовать OpenID Connect. Перерыл кучу инфы и не нашел как это сделать. Для более продвинутого Angular примеры есть, а вот для AngularJS нет ничего.

Можете кто уже делал подобное ?

[tessob]

Кучу раз делал. Если вы в AWS, то прописываете в ALB параметры вашего идентити провайдера и при запросе АЛБ будет смотреть на то, есть ли у вас токен:
1) если да, то верифицирует внутри себя и пропустит
2) если нет, то редиректнет к идентити провайдеру, который после успешного логина редиректнет пользователя взад

На чем у вас написан фронт — это вообще значения не имеет. Это задача админов/девопсов. Если у вас вместо AWS ALB стоит Nginx, то тогда или плагин если не про, или стандартными средствами, если про.

В сети полно пошаговых мануалов.

Сорри за сумбур, пишу на ходу.

[shadow7256]

Спасибо, но все равно непонятно немного. Мне нужно знать, как в реализовать OpenID Connect в самом коде (в AngularJS) ну или если есть какая нибудь библиотека для этого. AWS тут как бы не причем. Причем требование чтобы был реализован Authorization with PKCE workflow.

МЫ вроде нашли компонент под названием PlusAuth

https://github.com/PlusAuth/oidc-client-js

Но затыка происходит на моменте, когда Identity Provider возвращает authorization code. Следующим шагом по идее должно быть обращение к token endpoint в сторону IDentity Provider'a но вот никак..

[tessob]

В ангуларе никак. Он тут вообще не при чем. При попытке получить доступ к ресурсу (.html, .js, .css, etc.) прокси проверяет наличие токена. Если токена нет, то пользователь редиректится (302) к идентити провайдеру, который уже показывает ему форму с логином и паролем, MFA и любыми дополнительными проверками. Если пользователю удалось доказать, что он тот за кого себя выдаёт, то его редиректит обратно (302), но уже с токеном, прокси проверяет токен и пропускает его дальше. После этого пользователь выкачивает в браузер ассеты хоть на ангуларе, хоть на реакте.

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

[BronenosezPotemkin]

Я делала, но для нового ангуляра, используя эту библиотеку: https://github.com/okta/okta-auth-js.
Вроде старый она тоже поддерживает. Вот какой-то пример: https://phpflow.com/misc/angular/okta-a ... avascript/

[shadow7256]

Я делала, но для нового ангуляра, используя эту библиотеку: https://github.com/okta/okta-auth-js.
Вроде старый она тоже поддерживает. Вот какой-то пример: https://phpflow.com/misc/angular/okta-a ... avascript/

Для нового Ангуляра то проблем быть не должно. Вроде у Окты есть там поддержка. А вот для старого AngularJS ни хрена. Мы вот пока пытаемся прикрутить этот PlusAuth, но пока трудно идет.

[shadow7256]

В ангуларе никак. Он тут вообще не при чем. При попытке получить доступ к ресурсу (.html, .js, .css, etc.) прокси проверяет наличие токена. Если токена нет, то пользователь редиректится (302) к идентити провайдеру, который уже показывает ему форму с логином и паролем, MFA и любыми дополнительными проверками. Если пользователю удалось доказать, что он тот за кого себя выдаёт, то его редиректит обратно (302), но уже с токеном, прокси проверяет токен и пропускает его дальше. После этого пользователь выкачивает в браузер ассеты хоть на ангуларе, хоть на реакте.

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

Да мы знаем в теории как работает OpenID Connect. Причем тут прокси ? У нас есть наше приложение, кототорое сейчас работает со стандартным Forms authentication. Кастомер сказал, что никакого Forms auth больше не будет, все логины по все приложения будут идти через один логин - через Окта. То есть в Окте будет создано приложение для нашего приложения, нам будет выдан issuer URL, Client ID и другие параметры. Все. Дальше мы уже сами должны будем обеспечить работу нашего приложения через Open ID Connect, получать в итоге ID Token и уже работать с ним. Никакой прокси тут не поможет.

Для других технологий (Angular, .NET, Java, PHP) у Окты есть компоненты готовые. Для AngularJS нет. AngularJS был выпущен в 2010м году. OpenID Connect - в 2014м.

[BronenosezPotemkin]

Я делала, но для нового ангуляра, используя эту библиотеку: https://github.com/okta/okta-auth-js.
Вроде старый она тоже поддерживает. Вот какой-то пример: https://phpflow.com/misc/angular/okta-a ... avascript/

Для нового Ангуляра то проблем быть не должно. Вроде у Окты есть там поддержка. А вот для старого AngularJS ни хрена. Мы вот пока пытаемся прикрутить этот PlusAuth, но пока трудно идет.

Эта библиотека okta-auth-js, в принципе, универсальная для любого javascript. Вы пример посмотрели, там как раз anguarjs?

[tessob]

Да мы знаем в теории как работает OpenID Connect. Причем тут прокси ?

Прокси при том, что это та часть схемы, которая либо проксирует запрос, либо нет, в зависимости от наличия токена. Использование библиотек во фронте -- это просто абсурд, т.к. как все, что вы там на аутентифицирете вы в итоге отправите на публичные незащищенные API. Т.е. обход вашей безопасности сможет сделать любая QA-макака просто по неосторожности, например посмотрев на вкладку network в хроме. У вас же весь код всех ваших фронтовых библиотек выполняется в браузере злоумышленника. Если API защищенные, то тогда не понятно, что вы собираетесь изображать во фронте.

[shadow7256]

Да мы знаем в теории как работает OpenID Connect. Причем тут прокси ?

Прокси при том, что это та часть схемы, которая либо проксирует запрос, либо нет, в зависимости от наличия токена. Использование библиотек во фронте -- это просто абсурд, т.к. как все, что вы там на аутентифицирете вы в итоге отправите на публичные незащищенные API. Т.е. обход вашей безопасности сможет сделать любая QA-макака просто по неосторожности, например посмотрев на вкладку network в хроме. У вас же весь код всех ваших фронтовых библиотек выполняется в браузере злоумышленника. Если API защищенные, то тогда не понятно, что вы собираетесь изображать во фронте.

Мы наверное говорим о разных вещах Нам нужна authentication, а не authorization. Мы заменяем Forms authentication, при котором данные пользователя хранятся в aspnetdb базе данных, на Single Sign On механизм, при котором в качестве Identity Provider выступает Okta. У пользователя стоят куча разных приложений и во все эти приложения он логинится используя один и тот же логин.

[tessob]

Мы наверное говорим о разных вещах Нам нужна authentication, а не authorization. Мы заменяем Forms authentication, при котором данные пользователя хранятся в aspnetdb базе данных, на Single Sign On механизм, при котором в качестве Identity Provider выступает Okta. У пользователя стоят куча разных приложений и во все эти приложения он логинится используя один и тот же логин.

Я про authentication и говорю. Если вы там во фронте что-то там аутентифицируете, то как об этом узнает бек?

[shadow7256]

Мы наверное говорим о разных вещах Нам нужна authentication, а не authorization. Мы заменяем Forms authentication, при котором данные пользователя хранятся в aspnetdb базе данных, на Single Sign On механизм, при котором в качестве Identity Provider выступает Okta. У пользователя стоят куча разных приложений и во все эти приложения он логинится используя один и тот же логин.

Я про authentication и говорю. Если вы там во фронте что-то там аутентифицируете, то как об этом узнает бек?

мы гоняем JWT в каждом запросе, но это уже другая история. Данная история имеет конкретную цель - как использовать AngularJS и Okta.

[shadow7256]

Я делала, но для нового ангуляра, используя эту библиотеку: https://github.com/okta/okta-auth-js.
Вроде старый она тоже поддерживает. Вот какой-то пример: https://phpflow.com/misc/angular/okta-a ... avascript/

Для нового Ангуляра то проблем быть не должно. Вроде у Окты есть там поддержка. А вот для старого AngularJS ни хрена. Мы вот пока пытаемся прикрутить этот PlusAuth, но пока трудно идет.

Эта библиотека okta-auth-js, в принципе, универсальная для любого javascript. Вы пример посмотрели, там как раз anguarjs?

Я скинул ссылку девелоперу, который над этим работает. Спасибо, он посмотрит.

[KVA]

Неспешно у вас разработка идет ... Вопрос 5го Апреля, дев. посмотрит 22го.

[shadow7256]

Я делала, но для нового ангуляра, используя эту библиотеку: https://github.com/okta/okta-auth-js.
Вроде старый она тоже поддерживает. Вот какой-то пример: https://phpflow.com/misc/angular/okta-a ... avascript/

мы переключились на Okta-auth-js библиотеку, но все равно проблема осталась.

Запрос уходит на authorization endpoint на Okta и срабатывает callback и мы получаем authorization code назад. Но по идее теперь нужно сделать второй запрос на token endpoint и передать этот aothorization code чтобы в ответ получить ID token. Но вот как сделать этот второй запрос мы пока понятия не имеем

[KVA]

Там по второму линку в коде это есть. Не работает?

Code: Select all

Promise.all([
        authClient.tokenManager.get('idToken')
])
      .then(([idTokenObject]) => {
        localStorage.setItem("username", idTokenObject['claims']['name']);
        $scope.username = localStorage.getItem("username");
        console.log($scope.username);
        //return authClient.token.getUserInfo(accessTokenObject, idTokenObject);
      });

[shadow7256]

Там по второму линку в коде это есть. Не работает?

Code: Select all

Promise.all([
        authClient.tokenManager.get('idToken')
])
      .then(([idTokenObject]) => {
        localStorage.setItem("username", idTokenObject['claims']['name']);
        $scope.username = localStorage.getItem("username");
        console.log($scope.username);
        //return authClient.token.getUserInfo(accessTokenObject, idTokenObject);
      });

Эта часть кода у нас почему то не срабатывает Вторая ветка там где вызывается signInWithRedirect срабывает, мы получаем страницу с логином от Окты, логинимся и Окта нас возвращает обратно, но вот дальше по идее библиотека должна сама запросить ID token у Окты.. но почему то не идет..наверное что то не то с routing мы делаем

[KVA]

Ну так побегать по javascript и посмотреть что она там делает внутри? Все же как на ладони должно быть.

[IvanGrozniy]

Уважаемые,

Имеем SPA приложение, написано на AngularJS (важно. На старинном AngularJS). Кастомер хочет, чтобы это приложение использовало Single Sign On и в качестве Identity Provider использовало Okta. В самой Окте нам сказали, что для этого нужно использовать OpenID Connect. Перерыл кучу инфы и не нашел как это сделать. Для более продвинутого Angular примеры есть, а вот для AngularJS нет ничего.

Можете кто уже делал подобное ?

Я делал лет 5 назад такое. Но на веб-приложении написанном на ASP.Net как раз с использованием AngularJS. У них есть удобная функциональнасть для перехвата все запросов к серверу с проверкой если токены для аутенфикации присутствуют, если нет, то тогда редирект можно запрограммировать по стандартам open auth на сервер с процессом логина (настраивается в web.config ). То есть проверка наличия аутентификации идет на сервере. Если токена нет, то он сам ответ дают в браузер пользователя на редиретк в Окту. Окта потом обратно делает редирект уже с токеном после аутентификации. В самом javascript ничего делать не нужно было. То есть AngularJS как бы и нипричем был.
Я не знаю как там в Sap работает. Наверняка, что-то похожее есть. Найдите где этот ивент можно перехватить, а проверить токены и сделать редирект на сайт провайдера юзеров сделать самому. Это возможно, даже если вручную запрограммировать.
Помню вся эта байда работала с МС сервисами и с Октой. Могла и работать с фейсбуковскими паролями по этому стандарту.

[shadow7256]

Уважаемые,

Имеем SPA приложение, написано на AngularJS (важно. На старинном AngularJS). Кастомер хочет, чтобы это приложение использовало Single Sign On и в качестве Identity Provider использовало Okta. В самой Окте нам сказали, что для этого нужно использовать OpenID Connect. Перерыл кучу инфы и не нашел как это сделать. Для более продвинутого Angular примеры есть, а вот для AngularJS нет ничего.

Можете кто уже делал подобное ?

Я делал лет 5 назад такое. Но на веб-приложении написанном на ASP.Net как раз с использованием AngularJS. У них есть удобная функциональнасть для перехвата все запросов к серверу с проверкой если токены для аутенфикации присутствуют, если нет, то тогда редирект можно запрограммировать по стандартам open auth на сервер с процессом логина (настраивается в web.config ). То есть проверка наличия аутентификации идет на сервере. Если токена нет, то он сам ответ дают в браузер пользователя на редиретк в Окту. Окта потом обратно делает редирект уже с токеном после аутентификации. В самом javascript ничего делать не нужно было. То есть AngularJS как бы и нипричем был.
Я не знаю как там в Sap работает. Наверняка, что-то похожее есть. Найдите где этот ивент можно перехватить, а проверить токены и сделать редирект на сайт провайдера юзеров сделать самому. Это возможно, даже если вручную запрограммировать.
Помню вся эта байда работала с МС сервисами и с Октой. Могла и работать с фейсбуковскими паролями по этому стандарту.

по иронии судьбы мы именно так и сделали с другим нашим приложением. У нас еще одно есть SPA приложение (сделано на backbone.js). Кастомер тоже сказал, чтобы это приложение работало через SAML.

ОДин наш дев (который уже ушел от нас) создал простое ASP.NET MVC приложение (как обертка), в которое и засунул этот SPA. Создали простой View в котором есть <div> куда передается Okta username и в этом же View грузится само SPA, которое на ран тайме считывает из Дива информацию готовую уже. Вроде все получилось.

НО вот с этим AngularJS так не получается..

[BronenosezPotemkin]

мы переключились на Okta-auth-js библиотеку, но все равно проблема осталась.

Запрос уходит на authorization endpoint на Okta и срабатывает callback и мы получаем authorization code назад. Но по идее теперь нужно сделать второй запрос на token endpoint и передать этот aothorization code чтобы в ответ получить ID token. Но вот как сделать этот второй запрос мы пока понятия не имеем

Может, неправильный redirectUri? Выдаётся какая-то ошибка? Обычно в можно её увидеть в самом url или в консоле. Вы используете pkce flow? Если нет, надо в конфиге поставить false:

Code: Select all

 To use the authorization_code flow, set responseType to "code" and pkce to false:

var config = {
  // Required config
  issuer: 'https://{yourOktaDomain}/oauth2/default',
  clientId: 'GHtf9iJdr60A9IYrR0jw',
  redirectUri: 'https://acme.com/oauth2/callback/home',

  // Use authorization_code flow
  responseType: 'code',
  pkce: false
};

[shadow7256]

Да, мы используем PKCE, таково требование Окты. Redirect URL стоит такой - https://localhost:9700. Так как указано в примере с okta-auth-js. Редирект от Окты обратно идет и выглядити так:

https://localhost:9700/?code=asdfas7097 ... gdfgt45453

то есть Okta authorizatiton endpoint вернула нам обратно authorization code и по идее Okta-auth-js библиотека должна потом отправить этот code на token endpoint в Окту и получить ID token и оттуда вытащить username. Но никакого запроса на token endpoint не идет.. видно что то мы не так делаем с этой okta-auth-js

[BronenosezPotemkin]

Да, мы используем PKCE, таково требование Окты. Redirect URL стоит такой - https://localhost:9700. Так как указано в примере с okta-auth-js. Редирект от Окты обратно идет и выглядити так:

https://localhost:9700/?code=asdfas7097 ... gdfgt45453

то есть Okta authorizatiton endpoint вернула нам обратно authorization code и по идее Okta-auth-js библиотека должна потом отправить этот code на token endpoint в Окту и получить ID token и оттуда вытащить username. Но никакого запроса на token endpoint не идет.. видно что то мы не так делаем с этой okta-auth-js

Тогда вам, я думаю, не нужно использовать signInWithRedirect , у вас получается вот этот случай:

Code: Select all

Handling the callback without routing
Most applications will handle an OAuth callback using a special route/page, separate from the signin page. However some SPA applications have no routing logic and will want to handle everything in a single page.

Create / configure your auth-js instance
Before starting the OktaAuth service, or making any other API calls with auth-js , call token.isLoginRedirect - if this returns true, call token.parseFromUrl and save tokens using tokenManager.setTokens. It’s important that no other app logic runs until the async parseFromUrl / token manager logic is complete
After this, continue normal app logic.

То есть попробуйте вместо await authClient.handleLoginRedirect() в примере сделать await authClient.token.parseFromUrl() и authClient.start() вызвать после

Code: Select all

async function main() {
  // create OktaAuth instance
  var config = {
    issuer: 'https://{yourOktaDomain}/oauth2/default',
    clientId: 'XXXX',
    redirectUri: 'appurl',
  };
  authClient = new OktaAuth(config);

  // Subscribe to authState change event.
  authClient.authStateManager.subscribe(function(authState) {
    // Logic based on authState is done here.
    if (!authState.isAuthenticated) {
      // render unathenticated view
      return;
    }

    // Render authenticated view
  });

  // Handle callback
  if (authClient.token.isLoginRedirect()) {
    const { tokens } = await authClient.token.parseFromUrl(); // remember to "await" this async call
    authClient.tokenManager.setTokens(tokens);
  }

  // normal app startup
  authClient.start(); // will update auth state and call event listeners
}

[BronenosezPotemkin]

Code: Select all

if (authClient.isLoginRedirect()) {
    const { tokens } = await authClient.token.parseFromUrl(); // remember to "await" this async call
    authClient.tokenManager.setTokens(tokens);
} else{
    Promise.all([
        authClient.tokenManager.get('idToken')
    ]).then(([idTokenObject]) => {
            if (!idTokenObject) {
                authClient.token.getWithRedirect();
            }
        });
}

Что-то типа этого должно быть. В синтаксе могу ошибаться, не помню уже первый ангуляр.
tokenManager сам запишет token в localStorage. Тот phpflow пример выглядит устаревшим.

[IvanGrozniy]

Уважаемые,

Имеем SPA приложение, написано на AngularJS (важно. На старинном AngularJS). Кастомер хочет, чтобы это приложение использовало Single Sign On и в качестве Identity Provider использовало Okta. В самой Окте нам сказали, что для этого нужно использовать OpenID Connect. Перерыл кучу инфы и не нашел как это сделать. Для более продвинутого Angular примеры есть, а вот для AngularJS нет ничего.

Можете кто уже делал подобное ?

Я делал лет 5 назад такое. Но на веб-приложении написанном на ASP.Net как раз с использованием AngularJS. У них есть удобная функциональнасть для перехвата все запросов к серверу с проверкой если токены для аутенфикации присутствуют, если нет, то тогда редирект можно запрограммировать по стандартам open auth на сервер с процессом логина (настраивается в web.config ). То есть проверка наличия аутентификации идет на сервере. Если токена нет, то он сам ответ дают в браузер пользователя на редиретк в Окту. Окта потом обратно делает редирект уже с токеном после аутентификации. В самом javascript ничего делать не нужно было. То есть AngularJS как бы и нипричем был.
Я не знаю как там в Sap работает. Наверняка, что-то похожее есть. Найдите где этот ивент можно перехватить, а проверить токены и сделать редирект на сайт провайдера юзеров сделать самому. Это возможно, даже если вручную запрограммировать.
Помню вся эта байда работала с МС сервисами и с Октой. Могла и работать с фейсбуковскими паролями по этому стандарту.

по иронии судьбы мы именно так и сделали с другим нашим приложением. У нас еще одно есть SPA приложение (сделано на backbone.js). Кастомер тоже сказал, чтобы это приложение работало через SAML.

ОДин наш дев (который уже ушел от нас) создал простое ASP.NET MVC приложение (как обертка), в которое и засунул этот SPA. Создали простой View в котором есть <div> куда передается Okta username и в этом же View грузится само SPA, которое на ран тайме считывает из Дива информацию готовую уже. Вроде все получилось.

НО вот с этим AngularJS так не получается..

Юзер нэйм при правильном подходе внедрения в OpenAuth никуда передаваться не должен насколько я помню. В этом-то вся и фишка - не гонять чувствительную информацию по интернету. Юзер нейм и пароль сама Окта решит, спрашивать человечка или так доверить, по старой итентификации, айпи и т.д. Потом окта генерит токен базируяс на этой инфе и редиректит обратно в ваше приложения. Тогда она и может включить юзер нейм в токен, если настроить. Задача вашего приложения редирет сделать в окту при отсутствии токена (сгенерировать ответ кода 302 на запрос какой-нибудь странички без токена) и принять редирект обратно с токеном. Там еще детали есть, что это токен прийдется проверить по правилам.
Повторюсь - при правильном подходе аутентификация целиком делается на серверной части! На C#, например. JavaScript вообще не нужен для этого. Соотвественно, AngularJS вообще не нужно трогать.
Но это сложная тема. Я потратил на изучение OpenAuth и полное внедрение пару месяцев. Также из моего личного опыта - объяснение как это работает другим программистам тоже неявная задача. Если программист не в теме и начинает этим заниматься и спрашивает вопросы у внедривших такую систему, то примерно пару недель занимает, чтобы чел хоть что-то начинал понимать.