Какой поток авторизации OpenID Connect используется для аутентификации пользователей мобильных приложений?

Я создаю кросс-платформенное мобильное приложение, которое взаимодействует с RESTful API, и я хочу использовать OpenID Connect для аутентификации моих пользователей. Я буду строить собственный сервер поставщика OpenID Connect.

OpenID.net утверждает, что:

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

Однако я не могу найти документацию, объясняющую, как фактически аутентифицироваться для клиента мобильного приложения.

Этот ответ в StackExchange дает понять, что OpenID Connect не поддерживает поток предоставления ресурсов на основе ресурса или потоки клиентских учетных данных.

Это просто оставляет поток "авторизационного кода" (обычно используемый серверными приложениями) и поток "неявный грант" (обычно используемый клиентскими приложениями). Оба они, похоже, полагаются на перенаправление пользователя на конечную точку авторизации провайдера и перенаправление провайдера обратно на URL-адрес клиента. Я не вижу, как это применимо к мобильному приложению.

Может кто-нибудь объяснить мне (или даже лучше, указать мне на учебник или какой-то примерный код), который объясняет, как это сделать?

Update

Чтобы уточнить: OpenID Connect полагается на клиента, перенаправляющего пользователя на конечную точку авторизации, а затем поставщик перенаправляет пользователя клиенту. В случае, если клиент не является веб-приложением, как это работает?

Ответ 1

Мобильные приложения, по крайней мере, на iOS и Android, могут регистрировать собственные схемы URL-адресов, чтобы перенаправление из браузера могло отправить пользователя обратно в ваше приложение вместе с некоторыми параметрами запроса.

Таким образом, вы можете использовать эти потоки в родном мобильном приложении, но это связано с отправкой пользователя в веб-браузер (либо внешнее приложение-браузер, либо веб-представление, встроенное в ваше приложение), чтобы они могли аутентифицироваться с помощью OP.

Однако мои мысли по всему этому относятся к тому, что, поскольку вы разрабатываете свой собственный OP-сервер и свое собственное мобильное приложение, мобильное приложение действительно является доверенным клиентом, и нет ничего плохого в том, что пользователи непосредственно вводят свое имя пользователя и пароль в ваше приложение. Я понимаю, почему это не поддерживается спецификацией OpenID Connect, потому что это не проблема, которую OIDC пытается решить, и она может побуждать сторонние приложения запрашивать у пользователей прямое имя пользователя + пароль. Тем не менее, я бы хотел, чтобы в этой спецификации было больше рекомендаций по этому вопросу, поскольку я столкнулся с похожим сценарием с вами и не знаю, как действовать дальше.

Ответ 2

Я думаю, что Гибридный поток из спецификации OpenID Connect, вероятно, тот, который вы хотите использовать. OpenID Connect Core Spec.

Это зависит от наличия настроенного URI возврата, но, как говорит Джеймс, вы будете использовать схему URI клиента, чтобы мобильная ОС могла перенаправляться после входа в ваше собственное приложение. Тогда ваше приложение будет иметь код доступа, который он может использовать для получения токенов доступа по мере необходимости (при условии, что вы используете Oauth2 для защиты ваших внутренних API-сервисов, которые использует мобильное приложение).

Уязвимость существует из-за уязвимости, позволяющей злоумышленнику захватить вашу схему URI и захватить токены. Существует спецификация проекта, чтобы преодолеть этот Proof Key for Обмен кодами от публичных клиентов OAuth, который стоит рассмотреть при внедрении.

Ответ 3

Отметьте проект MITREid на github:

Подключение MITREid

Этот проект содержит эталонную реализацию OpenID Connect в Java на платформе Spring, включая функционирующую библиотеку серверов, развертываемый серверный пакет, клиентская (RP) библиотека и общая утилита библиотеки. Сервер может использоваться как идентификатор OpenID Connect Провайдера, а также универсальный сервер авторизации OAuth 2.0.