Open ID Connect и собственное общедоступное приложение... нет неявного потока, нет гибридного потока... и что?
В настоящее время мы разрабатываем собственное мобильное приложение, и нам необходимо аутентифицировать конечного пользователя с помощью нашего сервера идентификации (созданного с помощью сервера удостоверений ThinkTect Server v3) и / или внешних поставщиков социальных идентификаторов, чтобы использовать некоторые ресурсы в нашей системе.
Мы пытаемся использовать OIDC для получения токена доступа и токена id. В идеальном мире мы хотим, чтобы конечный пользователь собственного мобильного приложения оставался в системе на неопределенный срок (даже после перезагрузки собственного приложения), пока конечный пользователь не решит выйти из системы.
Итак, во-первых, мы выбрали неявный поток. Но мы обнаружили, что токены обновления НЕ доступны в этом потоке.
1. почему неявная спецификация потока запрещает обновлять токены? где опасность?
2. Другими словами, почему конечная точка токена не "достижима" неявным потоком?
Затем мы протестировали гибридный поток, чтобы получить токены обновления (очень, очень долгоживущие, но отзывные) и токен доступа (недолговечные). Проблема заключается в том, чтобы встроить client_secret в собственный публичный клиент. (плохая и небезопасная практика, как описано в спецификации OIDC)
3) Итак... родное общедоступное приложение не может использовать гибридный поток... а?
Итак, в настоящее время мы задаемся вопросом, является ли хорошей идеей решение с пользовательским потоком кода: создайте веб-API "proxy"/"front-end", который может достичь конечной точки токена с помощью своего собственного защищенного client_secret и т. Д., Передает код / refresh_token / access_token запрашивает из собственного клиентского приложения конечную точку токена сервера авторизации?
пользовательский код потока изображения
4) Есть комментарии по этому поводу?
1 ответ
Неявное предоставление OAuth 2.0 в первую очередь подразумевает оптимизацию по сравнению с предоставлением кода авторизации для клиентов в браузере, которые не могут хранить секрет клиента, поэтому можно предположить, что эти клиенты также не могут хранить токен обновления в секрете, в меньше всего перезагружается, потому что проблемы одинаковые.
Вы можете использовать грант авторизационного кода и зарегистрировать свое собственное мобильное приложение в качестве общедоступного клиента, т.е. оно не будет иметь секрета клиента, а будет зарегистрированным redirect_uri,
Обратите внимание, что токен обновления не имеет никакого отношения к входу пользователя в систему и не используется для обновления состояния входа пользователя. Вы можете использовать его только для получения нового токена доступа для использования / действия от имени пользователя. Вы можете решить считать пользователя, вошедшего в систему навсегда, решением только в приложении после первоначального получения id_tokenнезависимо от состояния пользователя на Сервере авторизации (AS) или на любом из токенов (access_token/refresh_token/id_token). Если вы хотите учесть состояние входа в систему AS, вы можете отправить запрос на авторизацию с prompt=none Параметр и проверьте id_token или ошибку в ответе авторизации.