App2app provisioning что это
Между законом и пользователем: тренды в финтех-разработке
Финтех входит в возраст цифровой зрелости. Между классическими банками и стартапами необанкинга, глобальными экосистемами и узкоспециализированными приложениями продолжается борьба за потребителя.
Чтобы завоевать и удержать пользователя, уже недостаточно соответствовать запросам, необходимо смотреть в будущее и предугадывать тренды отрасли.
Главное — быть user friendly
Для финансовых сервисов мобильный интерфейс становится главным способом общения со своими пользователями. Удобство при работе с приложением — одно из основных конкурентных преимуществ на этом рынке. Разработчики стараются максимально вылизать UX — сократить количество шагов, которые необходимо совершить пользователю, чтобы выполнить целевое действие
При этом, необанки обязаны соблюдать то же законодательство, что и классические банки. Однако пользователям далеко не всегда понятно, почему для первичной регистрации в приложении требуется ввести много данных, предоставить документы или даже снять селфи. Объяснение простое — когда мы приходили в обычное отделение банка, все необходимые действия выполнял операционист. Теперь за этот процесс отвечает сам пользователь.
Один из вариантов улучшения UX — подготовить простые, понятные и удобные для ввода шаблоны и использовать автоподстановку данных.
Например, чтобы упростить механику регистрации пользователя, при вводе адреса можно использовать геопозицию мобильного устройства и автоматическую подстановку полученных данных в строку ввода. Клиенту достаточно подтвердить выбор или откорректировать ответ, если нужно. Пользователю останется только отредактировать их (при необходимости) и подтвердить ввод.
Еще одна крутая фича — распознавание текста по фото, например, когда нужно вводить паспортные данные.
Еще один пример: для ввода логина гораздо проще использовать номер телефона с СМС-авторизацией. Эта фича поможет сэкономить минимум 4 клика, если на этом этапе сделать стандартную автоматическую отправку кода для проверки на сервер и автозаполнение поля из сообщений.
Особенно важно уделить внимание двухфакторной аутентификации и восстановлению доступа.
Представьте, какой стресс испытывает пользователь, когда долго не может получить доступ к своим средствам. Задача разработчика — помочь пройти этот путь за минимальное количество действий, но с уверенностью, что в приложение зайдет именно клиент банка, а не третье лицо.
Карта в телефоне — Visa In-App Provisioning
Современный пользователь привык все делать в один клик. В том числе, расплачиваться виртуальной картой в интернет-магазине. А если у пользователя есть электронный кошелек (Apple Pay или Google Pay) и смартфон с NFC, то такая карта будет работать и в офлайне.
Причем путь от оформления карты до ее появления в электронном кошельке можно также сократить до одной кнопки — это избавит пользователя от копирования данных из приложения в приложение. За такую функциональность отвечает технология In-App Provisioning. Ее внедрение — основной запрос к разработчикам за последнее полугодие.
Пока возможность доступна не всем. Для того, чтобы в приложении появилась кнопка «Добавить карту в кошелек», банку необходимо пройти проверку напрямую у Apple или Google, а затем получить одобрение от платежной системы, которая обслуживает платежи по картам (Visa или Mastercard). Только после этого нужно будет реализовать техническую часть задачи.
Вопросы безопасности
Основа основ любого финтех-приложения — безопасность.
Разработчику нужно соблюдать все требования международных стандартов по работе с платежными средствами Visa и Mastercard PCI/DSS, стандартов OWASP и OWASP-mobile.При этом само приложение должно остаться понятным и удобным для пользователя. Самая сложная задача — совместить требования безопасности и удобства пользования.
Современные банковские сервисы не стремятся выглядеть слишком серьезными и минималистичными. В интерфейс добавляются анимации и другие блоки, в приложениях появляются игры, тесты, чат-боты и изменение визуального оформления. Все это само по себе требует повышенного внимания к возможным ошибкам и уязвимостям.
Задача команды разработки — продумать пользовательский интерфейс и сценарии поведения пользователя таким образом, чтобы не только улучшить UX, но и обеспечить безопасность и выполнить все требования законодательства.
Кроме того, от посторонних взглядов, «под капотом», скрыт целый набор инструментов и сценариев, о которых также нужно позаботиться разработчику: зашифровать трафик, проверить отсутствие перехватчиков (man in the middle), обнаружить фрод-операции, отразить атаки на инфраструктуру (а они начинаются сразу, как только бизнес становится более-менее заметным), а еще соблюсти целый комплекс требований регуляторов по контролю.
Сбор данных и ограничения
Важный тренд последнего года — особое внимание к вопросам безопасности и защиты данных пользователей.
С недавнего времени бизнес получил возможность узнавать о пользователях буквально все — ведь у нас в руках оказалось устройство, которое следит за нашим положением, действиями и интересами в реальном времени. За это время интернет-гиганты (например, Apple или Facebook) научились собирать и анализировать данные и делать выводы о наших, предсказывать поведение. В самом безобидном случае пользователь становится объектом прицельной рекламы.
В ответ на подобные действия появились ограничения на сбор, обработку и передачу персональных данных третьим лицам, на использование cookies и трекинг в целом. Сегодня большой бизнес уже не может себе позволить думать о пользователях как об источниках данных: это и требование закона и, что важнее, требование клиентов.
В таких условиях компании ищут другие возможности для сбора данных о своей аудитории, ее предпочтениях, поведении и интересах. Например, есть a/b- тестирование функциональности или опросы внутри приложения — такие сервисы уже есть на рынке.
Мобильная версия — yes or not?
Ни один серьезный сервис сегодня уже не может позволить себе иметь только веб-версию. Все пользователи ожидают удобное мобильное приложение с полным функционалом.
Для бизнеса пользователи мобильных приложений в среднем имеют в 6-7 раз лучший показатель возврата в сервис, чем пользователи сайта и примерно в 1,5 раза лучший показатель доходности в среднем.
С другой стороны, требования по конфиденциальности данных и дополнительные действия, которые необходимо принять пользователю для установки приложений, усложняют работу маркетинга.
Значит ли это, что нужно вкладывать исключительно в развитие мобильных приложений и полностью отказаться от разработки сайта? Пока нет однозначного ответа. Опираться необходимо на нужный сегмент аудитории и особенности вашего сервиса.
В начале своего пути необанкам не нужен был сайт, они справлялись только с мобильным каналом. Последние пару лет ситуация изменяется, потому что крупные компании запускают и развивают с таким же усилием не только приложения, но и веб-сайты. Для одних это ориентация на новый сегмент аудитории, для других — сервисное решение, для третьих — способ диверсифицировать риски, защищаясь от возможного бана приложения в сторах.
Персонификация сервиса
Данные об операциях и запросах клиента внутри приложения позволяют не только предоставить пользователю графики его расходов и доходов, но и подготовить персональные предложения. Для анализа берутся данные скоринга и информация из CRM на стороне банка.
На практике это работает так: клиент несколько месяцев совершает покупки в среднем на 50 тысяч рублей, но мы видим, что на карту поступает ежемесячно 70 тысяч рублей заработной платы. Получив и обработав данную информацию, предполагаем, что с большой долей вероятности клиент будет готов вносить ежемесячный платеж до 20 тысяч рублей. Так со своей стороны можно предложить ему взять кредит на особых условиях. Дополнительно проанализировав категории покупок, сервис может предложить повышенный кэшбэк на популярные товары от партнеров.
Роль отзывов в разработке
Обратная связь в приложении — это возможность услышать мнения и отзывы пользователей. Отзывы помогают улучшать сервис, если регулярно заниматься их сбором и классификацией.
Существует методика, при которой новая функциональность внедряется и итеративно дорабатывается после получения фидбека на нее. Это гибкая разработка или продуктовый подход. Методика позволяет учитывать пожелания пользователей и создавать такие сервисы, которые идеально отвечают запросам пользователей.
Выводы
При разработке современных финтех-продуктов на первый план выходят вопросы клиентоцентричности и кибербезопасности. В онлайн массово переходит даже старшее поколение, мобильные приложения вытесняют из повседневной жизни классические пластиковые платежные карты, а сами финансовые операции становятся все более бесшовными и незаметными для потребителя.
Победителем становится тот, кто первым предлагает пользователю свободу и комфорт в работе с его деньгами: быстрое, надежное и удобное банковское приложение.
Для разработчика эти критерии сводятся к приоритетной задаче: удержать пользователя внутри приложения, не нарушая закон и соблюдая меры безопасности.
Опыт внедрения сервиса мобильных платежей Apple Pay в банке
В этой статье мы бы хотели поделиться своим практическим опытом внедрение сервиса мобильных платежей Apple Pay, какие проектные подходы мы использовали при решении этой непростой задачи, и какие моменты нужно учесть, если вы планируете внедрение этого сервиса у себя.
Не будем далее сильно вдаваться в технические детали внедрения (по этому поводу чуть позже выйдет отдельная статья), но если на пальцах, то вся инфраструктура Apple Pay состоит из следующих компонент, которые будет необходимо друг с другом подружить:
1. Платформа выпуска и управления жизненным циклом токена (виртуального «псевдо» номера карты) на стороне платежной системы. У MasterCard она называется Mastercard Digital Enablement Service (или MDES), у VISA — Digital Enablement Program (или VDEP)
2. Ваша карточная процессинговая система
3. Приложение мобильного банка
4. Сервис шифрования, необходимый для передачи данных в Apple и Платежную систему при привязке карты через мобильный банк (в терминологии Apple это называется In-app provisioning)
Если п.1 является коробочным решением и уже разработан (потребуется только небольшая настройка под ваши карточные продукты и специфику), по п.2 вендоры процессинговых решений (например OpenWay) предлагают частично или уже полностью реализованные доработки, то вот п.4 — сервис шифрования придется разрабатывать с нуля. Отнеситесь к планированию и реализации этой компоненты очень внимательно, так как у нас на ее отладку ушло больше всего времени и сил).
С одной стороны задача выглядит как классический проект (есть фиксированный срок запуска, понятен конечный результат), поэтому вооружайся water fall’ом и вперед, но с другой стороны очень важна скорость внедрения, качество (почему это важно, расскажем в конце статьи), и тот факт, что наш Банк сейчас повсеместно переходит на agile фрейм-ворки разработки (в частности, на Scrum). В итоге получился гибридный подход, не претендующий на идеальность, но подошедший нашей команде в период agile-трансформации:
• За точку отсчета был взят проектный план MasterCard и VISA (от этого никуда не уйти, у компаний свои стандартные процедуры ведения проектов, по которым работают они сами и взаимодействуют с внешним миром)
• План был дополнен внутренними работами (Процедуры бюджетирования и заключения договоров, разработкой архитектуры, утверждением решения с Информационной безопасность, доработкой внутренних систем, тестированиями, сертификацией и т.д.), а даты завершения проставлены таким образом, чтобы выйти на желаемую дату запуска (с запасом в 2 недели, конечно же). На основе этого плана была выявлена потребность в участниках проектной команды, и сформирована эта временная команда
• Далее мы распланировали регулярные конфколлы со всей командой (раз в неделю в начале проекта, 2 раза в неделю в середине, и каждый день по 15 минут на финальной стадии перед запуском), где брали текущие и будущие задачи из большого проектного плана, били их на под-задачи, назначали ответственных, рассылали на всех этот мини-план (он же протокол встречи) и работали по нему до следующего конфколла.
• Если проектный план «ехал» по датам, мы сразу же смело его меняли, чтобы он соответствовал действительности, и не делали из этого трагедию
• Как только тот или ной компонент был полностью готов и оттестирован, выводили его на боевую среду, и уже после вывода на бой какое-то время тестировали работу сервиса на закрытой группе реальных пользователей (все это были сотрудники банка)
• И так, маленькими шажками двигались к цели.
Если внимательно присмотреться, то можно увидеть некоторые аналогии с событиями и артефактами Scrum:
• Проектный план + спецификации Apple и платежных систем – это бэклог
• Декомпозиция проектного плана на под-задачи для работы до следующего еженедельного конфколла – это PBR и планирование спринта, длительностью в неделю
• Ежедневные конфколлы – daily scrum
Но были и отклонения от фрейм-ворка, в частности мы не делали ретроспективы, тестировали не в конце каждого спринта, а когда уже большая часть компонент была разработана и интегрирована на тестовой среде, и у нас не было демо.
Что интересно, данный подход именно «родился» по ходу работы, а не был спроектирован заранее, т.е. подстраивался под подробности команды. Надеемся, что эта история вдохновит Вас к экспериментам в области управления проектами, и более гибкому подходу для достижения целей.
Почему так важно внедрять Apple Pay очень качественно? Дело в том, перед запуском в коммерческую эксплуатацию вам придется пройти обязательное независимое тестирование (сертификацию) вашего решения, развернутого на бою, в одной из 3-х тестовых лабораторий, авторизированных Apple. И это будет непросто, дело в том, что лаборатории очень скрупулёзно подходят к тестированию (обычно оно занимает порядка 2х недель).
Например, будут проверены абсолютно все ваши дизайны карт на соответствие физического пластика и картинки в кошельке (причем, если расходится дизайн логотипа или цвет шрифта плохо читается на экране телефона, вас попросят эти недостатки срочно устранить), будут проверены все возможные сценарии использования, на всех поддерживаемых устройствах (включая IPad Pro 12” )), внимательно вычитаны Terms & Conditions (нас например, просили исправить в некоторых местах знаки препинания). В общем, Apple и партнеры относятся к выпуску продуктов очень внимательно, закрыть глаза на шероховатости не получится, и к этому нужно быть готовым заранее.
Итак, работы все выполнены, тестирование и сертификация пройдены, а решение запущено. Что мы имеем в остатке:
1. Выполненный проект;
2. Интересный опыт и необычный подход к решению проекта;
3. Несколько подразделений в компании, которые приняли практики, использованные на проекте и продолжают использовать подход к решению различных задач и проектов.
В следующей статье мы постараемся рассказать больше технических деталей и особенностей, с которыми вы столкнулись в ходе внедрения Apple Pay, а пока можете задавать вопросы в комментариях.
Кузин Сергей, scrum-мастер банка «Открытие»
Эксперт спрогнозировал рост оборота карт «Мир» в премиальном сегменте
Ожидается рост оборота по картам «Мир» после подключения к Apple Pay в связи тем, что карта данной платежной системы с возможностью добавления в продукты Apple станет более востребована в премиальном сегменте. Об этом заявил «Известиям» Александр Вдовин, главный архитектор департамента технологического развития СКБ-банка, комментируя сообщения пресс-службы «Мир» о том, что банки подключили карты этой системы к Apple Pay во вторник, 20 июля.
Бесконтакт налажен: карты «Мир» начнут подключать к Google Pay 26 октября
Как новая технология упростит использование национального пластика
По словам Вдовина, в премиальном сегменте традиционно выше средний чек, обороты и заинтересованность в продукции Apple. Он добавил, что нововведение, безусловно, мотивирует нынешних владельцев карт «Мир» активнее пользоваться ими. Эксперт отметил, что карты этой платежной системы сейчас принимаются в России везде, а их держатели ожидают возможности добавить их в один кошелек остальным своим картам, чтобы получать выгоды от программ лояльности системы «Мир», например, в транспорте.
Факт подключения «Мир» к Apple Pay благоприятно скажется на росте количества платежей по этим картам, заявил «Известиям» Дмитрий Попов, исполнительный директор платежного агрегатора IntellectMoney. Он рассказал, что к 2020 году Россия вышла на второе место в мире по числу пользователей Apple Pay. На сегодняшний момент, по его словам, насчитывается порядка 25 млн пользователей этого сервиса в стране, и все они теперь могут перейти в экосистему Национальной системы платежных карт (НСПК, оператор системы «Мир»). По его словам, РФ уступает по числу бесконтактных платежей в мире только США. «Что касается прогноза роста: за счет различных инициатив ЦБ и правительства РФ «Мир» уже растет на десятки процентов год к году», — сказал он. По словам Попова, если за подключением к Apple Pay последуют дальнейшие «логичные шаги» по подключению возможности совершать другие бесконтактные платежи, доля «Мира» в обороте безналичных операций может существенно вырасти, потеснив Visa и Mastercard.
Он выразил мнение, что если НСПК будет более активно работать с другими государствами и возможность расплачиваться картами «Мир» появится в большинстве стран, в сочетании с бесконтактными платежами это закроет большинство потребностей пользователей банковских карт. Владельцам карт этой платежной системы не будет смысла пользоваться картами других систем, заключил специалист. После реализации сервиса Apple Pay Московский кредитный банк (МКБ) прогнозирует увеличение оборота по картам «Мир» более чем на 20%, сообщила «Известиям» Татьяна Брюхина, начальник управления развития карточного бизнеса банка. Она добавила, что дополнительный прирост даст реализация функционала App2App provisioning, которая позволит держателем карт моментально привязать карту в мобильном приложении. «В целом токенизация банковских карт напрямую влияет на транзакционную активность клиентов и рост оборота по картам», — сказала Брюхина. Ранее в этот же день пресс-служба «Мир» сообщила, что владельцы карт этой системы теперь могут пользоваться функцией Apple Pay. Трансакции доступны на устройствах iPhone и Apple Watch, через приложение Apple Pay на iPhone, iPad или Mac и на сайтах, открытых в браузере Safari. Услугу для держателей карт «Мир» внедрили следующие российские банки: Сбербанк, ВТБ, Россельхозбанк, Промсвязьбанк, Почта банк, банк «Центр-инвест», Тинькофф банк и Примсоцбанк. Держатели карт «Мир» могут подключаться к Samsung Pay с августа 2019 года. С 26 октября этого года банки начнут подключать эти карты к Google Pay. До настоящего времени для оплаты картой «Мир» с помощью смартфона можно было пользоваться приложениями Mir Pay и Samsung Pay на базе Android. С 27 апреля банки могут токенизировать национальный «пластик» на устройствах Apple для платежей с помощью Apple Pay. Но пока ни одна кредитная организация не реализовала такой функционал.
App2App Mobile Architecture
App2App is a financial-grade design pattern where a mobile app can authenticate users via a separate high-security mobile app. This provides an out-of-the-box Strong Customer Authentication (SCA) solution.
The European Bank Authority is encouraging App2App as part of PSD2 implementations, and the Financial Grade API (FAPI) Working Group is including App2App in its FAPI-RW profile.
In this article, we will describe the App2App flow, then dive deeper into Open Banking solutions, where merchant apps can use App2App to login via a bank app.
App2App OpenID Connect Flow
The App2App flow is illustrated below, showing that the mobile app simply needs to open a browser at the identity server’s authorization endpoint. This requires login, which the authorization server handles by redirecting the browser to a URL registered on the mobile device. This URL is handled by a login application installed on the same device.
As a result, the login app is presented to the user, and the user signs in. The login app then invokes a URL that is again handled by the browser, which completes the authorization request by redirecting to the client app’s redirect URI. This brings up the app with the authorization code, representing the end user’s authorization. The app exchanges this for an access token, using PKCE to protect against redirect interception. The resulting token can then be used to call APIs.
The following technical steps are performed to sign the user in, manage browser redirects securely, then get tokens with which to call APIs:
Step | Description |
---|---|
1. App Opens System Browser | Before starting authentication, the client app presents a system browser, which will handle HTML responses |
2. Authorization Request Sent | The client app creates an OpenID Connect authentication request and sets the browser URL to trigger a login redirect |
3. Redirect Response Received | The client app receives a redirect response from the authorization server, containing a deep link URL to the login app |
4. Login Redirect Followed | The browser follows the login redirect, which lands on a page from which the user is deep linked to the login app |
5. User Authenticates | The end-user signs in via the login app, using multi-factor authentication |
6. Login Completes | The login app posts the login result to the authorization server (directly or indirectly) |
7. Polling Completes | During login, the system browser page in the client app polls the authorization server for a login result |
8. Authorization Code Returned | A login result is returned to the system browser containing an authorization code to complete the sign-in process, after which the browser is closed |
9. Access Token is Retrieved | The mobile app then swaps the authorization code for OAuth tokens |
10. Access Token is Used | The mobile app then uses the access token as a message credential when calling APIs |
Mobile AppAuth Implementation
Although the above picture has quite a few moving parts, the client app only needs to implement the AppAuth Pattern described in RFC8252. This can be done relatively easily by integrating the open-source libraries:
Library | Features |
---|---|
AppAuth for iOS | Invokes a Chrome Custom Tab browser window on which to perform logins, then handles all OAuth messages |
AppAuth for Android | Invokes an ASWebAuthenticationSession window on which to perform logins, then handles all OAuth messages |
User Onboarding
The Login App implements OpenID Connect via a Claimed HTTPS Scheme, which means an HTTPS URL is used for deep linking, using mobile platform features:
- iOS uses Universal Links
- Android uses App Links
Claimed HTTPS schemes prevent malicious mobile apps on user devices from registering the same URL and intercepting login responses. In this way, the scheme, combined with the mobile operating system’s key verification, establishes the provenance of the application. It also enables the following two scenarios to be handled gracefully for end-users:
User Scenario | Login Behavior |
---|---|
Login app is not installed | The client app’s browser renders a public web page to prompt the user to download and install the app |
Login app is already installed | The client app’s browser invokes the deep link URL to start the login app on the same device |
Specialist Security Apps
Some companies offer specialist apps to manage the mechanics of Multi-Factor Authentication (MFA). An example provider is BankID, which multiple banks can use as part of their mobile banking solutions.
App2App for Open Banking
In an Open Banking scenario, a merchant app can quickly meet its PSD2 Strong Customer Authentication (SCA) requirement by implementing App2App via a bank app. However, any real-world solution is likely to include merchant APIs, so the merchant will also need to protect their own data. In this case, the problem with the App2App flow is that bank access tokens are not designed to secure merchant APIs.
In the final step above, the merchant API receives an access token issued by the bank, and has little or no control over the following aspects:
Behavior | Potential Problem |
---|---|
Token Validation | It may not be possible to get keys needed to validate the received access token |
User Identification | It may not be possible to identify or match up users based on the token’s subject claim |
Scopes and Claims | It will not be possible for the merchant to provide its own scopes and claims to its APIs |
Lifetimes | The merchant will not be able to control lifetimes for access tokens or the mobile app’s user session |
Future Changes | The merchant APIs may break when the bank applies future unknown changes |
The standard solution to these problems is for both the merchant and the bank to use an authorization server.
Federated App2App Flow
The following sections will illustrate how the App2App flow changes when a merchant introduces an authorization server. A key point to understand is that this only requires security configuration changes — zero code changes are needed in the merchant’s mobile app.
Authentication
The flow during authentication now involves the Merchant Authorization Server calling the Bank Authorization Server to get the redirect URL to the bank login app:
There are also two different authorization codes issued, once login completes, which are also handled via browser redirects:
Token Issuance
When the app swaps code for tokens, the Merchant Authorization Server exchanges the bank authorization code for tokens at the Bank Authorization Server.
The Merchant Authorization Server then receives a Bank Access Token but also issues Merchant Access Tokens with whatever scopes and claims the merchant’s APIs require.
The bank token may then be embedded in the merchant token so that both are stored in the authorization server state. An opaque reference token is then returned to the Merchant Mobile App:
For further details on these token issuing patterns, and how merchant APIs would use scopes and claims, see the below articles:
- Phantom Token Pattern
- Token Sharing Techniques
- Scope Best Practices
- Claims Best Practices
API Calls
Finally, the merchant mobile app can initiate calls to both its own APIs and also to the bank’s API. The merchant APIs can implement authorization using scopes and claims from access tokens.
Calls to bank APIs typically need to be routed via the merchant’s API so that Mutual TLS can be used. During this downstream call, the merchant API forwards the bank token contained in the composite token.
Authentication Selection
App2App options can also be selected at runtime, since a key goal of Open Banking is to connect the following parties dynamically:
Party | Role |
---|---|
Bank | A bank acts as an ‘Account Servicing Payment Service Provider’ (ASPSP) and provides App2App solutions for multiple merchant apps |
Merchant | A merchant acts as a ‘Third Party Provider’ (TPP) and provides apps that integrate with multiple banks on behalf of consumers |
Consumer | A consumer acts as a ‘Payment Service User’ (PSU) and can use one or more bank accounts within the same or different merchant apps |
Selecting a Bank
Typically a merchant app will present a screen to sign in via one or more of the main banks. Each consumer will select a bank to sign in with and will then need to use that bank’s App2App flow. This sign-in process could be repeated multiple times for different banks.
The merchant app can use the Authentication Context Class Reference (acr) Claim, or the acr_values query parameter, to tell its authorization server which bank to use for the App2App login and to deep link straight to that bank’s app. After login, the app will also receive the acr claim in its id token.
API Authorization After Authentication
In some cases, such as if the user cannot authenticate with the bank, the merchant may provide a fallback authentication option with the following type of behavior:
Authentication Level | User Privileges |
---|---|
Standard Authentication | The user has basic privileges such as viewing their transaction history |
Strong Customer Authentication | The user can perform high privilege operations such as payments |
To enforce these rules during API authorization, the merchant can dynamically add a claim such as authentication_level to access tokens based on the runtime authentication method(s) used.
Adding this claim requires a capability to process the authentication context and apply custom logic during token issuance. In the Curity Identity Server this is possible using a Custom Claims Value Provider , which can inspect the authentication context and issue custom claims.
User Experience
In some ways, the AppAuth pattern is a little unnatural when logging on via a deep link to an external mobile app, since the user sees the system browser popup and then disappear, but the browser does not render anything:
With the Curity Identity Server, an alternative approach is to bypass the browser and use the Hypermedia Authentication API (HAAPI) , which has usability, security, and deployment benefits.
App2App Tutorial
The App2App via Hypermedia Authentication API tutorial shows how to get App2App working with the Curity Identity Server. This is done via a small mobile code sample that signs the user in via a deep link to the BankID app.
Conclusion
By implementing the OpenID Connect App2App flow, Strong Customer Authentication (SCA) requirements can be met via an out-of-the-box solution, where all of the security complexity is outsourced.
For Open Banking solutions, merchants also need to protect their own data, and should use a federated form of App2App. With the correct design choices, a full end-to-end solution requires only simple code.
Watch this free webinar to learn more about App2App Login with Authentication Workflows
Join our Newsletter
Get the latest on identity management, API Security and authentication straight to your inbox.
Start Free Trial
Try the Curity Identity Server for Free. Get up and running in 10 minutes.
- Home
- Resources
- Financial Grade
- App2App Mobile Architecture