Могу ли я использовать OAuth для аутентификации доверенного клиента (мобильное приложение)?

Question

Я знаю, как работают OAuth2 и OpenID Connect. Но меня все еще беспокоит некоторое замешательство.

Мы разрабатываем собственный Auth Server, сервисный API и мобильное приложение. Итак, клиентское приложение является доверенным, и мы используем тип предоставления «пароль». Пользовательский репозиторий приложения следует той же базе данных пользователей на сервере аутентификации.

Наши клиенты входят в приложение по имени пользователя / паролю. Затем приложение отправляет учетные данные пользователя в конечную точку токена сервера аутентификации, которая возвращает клиенту токен доступа (однонаправленный) и токен идентификатора (JWT). Идентификационный токен содержит основную информацию о пользователе, поэтому приложение может приветствовать пользователя, например «Добро пожаловать, Тони Старк!». Маркер доступа можно использовать для доступа к API (например, обновить профиль пользователя).

OAuth по замыслу не является инструментом для аутентификации. Ссылка: https://www.scottbrady91.com/OAuth/OAuth-is-Not-Authentication

Мои вопросы

1) Нужно ли проверять подпись идентификационного токена, если клиенту только интересно получить информацию о пользователе? Также обратите внимание, что идентификатор токена поступает из конечной точки токена через соединение https.

2) Давайте забудем о токене ID. Можем ли мы считать, что пользователь прошел проверку подлинности (т. Е. Успешно выполнен вход в систему), если клиент получает токен доступа с сервера проверки подлинности? Этот поток очень похож на простой пароль входа без OAuth.

3) Клиент может получить доступ к защищенным API с помощью токена доступа. Без маркера доступа клиент может вызывать только некоторые общедоступные API. Это эквивалентно тому, что можно сделать с и без входа в систему? Похоже, маркер доступа может рассматриваться как «cookie сеанса входа в систему».

4) В моем случае нет участия третьей стороны. Все (клиент, сервер аутентификации, сервис API) разработано и принадлежит одной организации. Имеет ли смысл использовать OAuth?

Answer 1

1) Нужно ли проверять подпись идентификатора токена, если клиент заинтересован только в получении информации о пользователе?Также обратите внимание, что ID-токен поступает из конечной точки токена через соединение https.

ДА.

2) Давайте забудем о ID-токене.Можем ли мы обработать, что пользователь прошел проверку подлинности (т.е. успешность входа в систему), если клиент получает токен доступа с сервера проверки подлинности?Этот поток очень похож на простой пароль входа без OAuth.

Если я понимаю предпосылку.Да. Для использования идентификатора токена не требуется.

3) Клиент может получить доступ к защищенным API с помощью токена доступа.Без маркера доступа клиент может вызывать только некоторые общедоступные API.Это эквивалентно тому, что можно сделать с и без входа в систему?Похоже, маркер доступа можно рассматривать как «cookie сеанса входа в систему».

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

4) В моем случае нет участия третьей стороны.Все (клиент, сервер аутентификации, сервис API) разработано и принадлежит одной организации.Имеет ли смысл использовать OAuth?

Да.OAuth и OpenID Connect используются многими, многими организациями и являются тестовым решением.

Не пытайтесь изобретать «колесо» заново.Используйте известные доверенные библиотеки для аутентификации, авторизации и криптографических операций. OpenID Connect имеет несколько сертифицированных реализаций

Answer 2

Обычно мобильное приложение считается публичным клиентом. Если вы не ограничиваете доступ к мобильному приложению, его нельзя считать доверенным, поскольку кто-то может связываться с приложением вне вашего контроля, даже если вы его разработали.

Кроме того, тип предоставления учетных данных ресурса, как правило, не очень хорошая идея. Во-первых, для спецификации OpenID Connect требуется код авторизации, токен id или гибридный поток:

Аутентификация может идти по одному из трех путей: Код авторизации Поток (response_type = code), неявный поток (response_type = id_token токен или response_type = id_token), или гибридный поток (с использованием других Значения типа ответа, определенные в множественном типе ответа OAuth 2.0 Практика кодирования [OAuth.Responses]).

Некоторые другие причины: Почему тип предоставления учетных данных пароля владельца ресурса не подходит для аутентификации и не подходит для современных приложений

1. В RFC OpenID Connect говорится, что вы ДОЛЖНЫ проверить идентификационный токен:

При использовании неявного потока содержимое идентификатора токена ДОЛЖНО проверяться таким же образом, как и для потока кода авторизации, как определено в разделе 3.1.3.7, за исключением различий, указанных в этом разделе.

Хотя вы можете претендовать на это исключение из 3.1.3.7 при использовании TLS:

Если идентификационный токен получен посредством прямой связи между клиентом и конечной точкой токена (который находится в этом потоке), проверка TLS-сервера МОЖЕТ использоваться для проверки эмитента вместо проверки подписи токена. Клиент ДОЛЖЕН проверять подпись всех других токенов ID в соответствии с JWS [JWS], используя алгоритм, указанный в параметре заголовка JWT alg. Клиент ДОЛЖЕН использовать ключи, предоставленные Эмитентом.

2. Если вы можете доверять клиенту и выполненной вами проверке пользователя / пароля, то вы должны быть в состоянии доверять тому, что токен доступа был предоставлен аутентифицированному идентификатору в соответствии с OAuth 2.0 спецификация.

3. Маркер доступа в OAuth 2.0 также содержит области действия и должен ограничивать то, что можно сделать с этим токеном доступа. Логин без OAuth не обязательно.

4. Рекомендуется использовать OAuth для защиты учетных данных владельца ресурса. Если бы вы использовали тип предоставления учетных данных владельца ресурса, это все равно дает некоторые преимущества, поскольку пользователь может вводить пароль только в том случае, если у клиента нет действительного токена доступа, т. Е. Пользователь может один раз ввести свой пароль для токена доступа. и подтвердите пользователя, используя его вместо повторного ввода пароля или его сохранения где-либо.

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

OAuth 2.0 RFC6749