Внедрение кода авторизации Oauth2 Поток грантов вручную

Question

Я планирую реализовать поток предоставления кода авторизации Oauth2 (с PKCE) вручную. Мой вопрос частично связан с this . Я использую Java, Springboot.

Я хочу защитить свои бэкэнд-API с помощью Oauth. Эти API-интерфейсы называются родным приложением. Большинство реализаций Oauth для предоставления кода авторизации требуют взаимодействия с пользователем. Мне было интересно, если это возможно, чтобы избежать этого. Поскольку мое приложение работает на собственном приложении, я не хочу, чтобы пользователь перенаправлялся в браузер для аутентификации. Мое приложение имеет функцию регистрации / входа.

Я планирую реализовать фильтр, в котором лог c будет выглядеть примерно так

if(uri contains authorize){
    get all details from request
    generate a uuid and store details in db with ttl
    return uuid as code.
}

else if(uri contains token){
    get all details from request
    extract code from request and check for validity in database.
    if(code valid) {
       generate a JWT with access_token with ttl and refresh_token
       return JWT
    }
}

else{
    check if JWT is present and valid
    if valid proceed
}

У меня также будет лог c для refre sh токен , Я хочу знать

1. Существуют ли какие-либо меры безопасности fl aws при таких действиях
2. Есть ли другой альтернативный способ достижения потока предоставления кода авторизации без взаимодействия с пользователем.
3. По отношению к PKCE. Использование PKCE уменьшает угрозу перехвата кода авторизации, не создавая и не сохраняя секрет клиента. Но что мешает пользователю отправить запрос конечной точке авторизации с его / ее собственным вызовом кода? Насколько безопасен идентификатор клиента в собственном приложении?

Answer 1

Прежде всего

Не повторяю, НИКОГДА не пытайтесь самостоятельно реализовать какую-либо форму индивидуальной защиты .

Это одна из худших вещей. ты можешь сделать. Безопасность сложна и часто требует реализации нескольких команд. Вот почему у нас есть стандартные библиотеки для этого. Используйте пружинную защиту.

Ответы на ваш вопрос:

1. Безопасность fl aws везде. Безопасность - это гораздо больше, чем просто небольшой фрагмент кода, который вы опубликовали. oauth2 - это стандарт с точными правилами относительно того, что и как вы проверяете и проверяете. Поэтому мой быстрый ответ - да, вы не следуете стандарту. Так что да, это небезопасно. Используйте пружинную защиту.

2. Нет, когда вы говорите о взаимодействии с пользователем, я понятия не имею, о чем вы говорите. Вы должны следовать определенному потоку, и если вы решили автоматизировать поток или нет, это ваше дело. Опишите, что именно вы АКТУАЛЬНО хотите сделать.

3. ClientIds или что-либо в этом роде никогда не безопасно в любом приложении. Все зависит от уровня безопасности, который вы ищете. Если мы говорим о корпоративной безопасности, вы обычно храните все секреты в бэкэнде и внедряете какой-то BFF для своего веб-приложения, которое хранит все клиентские секреты, а также выполняет обмены. Единственное, что хранится в клиенте, это другой тип безопасных файлов cookie.

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