Упростите доступ к базе данных PostgreSQL с помощью Neon Authorize

Объединяя встроенную в PostgreSQL защиту на уровне строк с внешними по отношению к базе данных провайдерами аутентификации, Neon Authorize предлагает новый, эффективный и прозрачный способ защиты доступа для приложений, управляемых базой данных.

Ключевая концепция, которую следует усвоить, заключается в том, что Neon занимается авторизацией, а аутентификация - управление идентификационными данными пользователей, паролями и токенами безопасности - по-прежнему осуществляется сторонними провайдерами аутентификации на основе JWT, такими как Auth0 и Clerk.

Что делает Neon, так это интегрирует внешнюю аутентификацию с внутренней авторизацией, требуемой базой данных, чтобы пользователь мог получить доступ к своим собственным строкам, расширяя встроенную в PostgreSQL систему Row Level Security. Давайте посмотрим пример в действии, включив RLS для таблицы 'departments' :

ALTER TABLE departments
ВКЛЮЧИТЬ ЗАЩИТУ НА УРОВНЕ СТРОК;

--Далее мы создаем политику

CREATE POLICY department_managers
ON departments
TO managers
USING (manager = current_user);

Теперь вам больше не нужно писать запросы на уровне приложения, такие как

select * from departments
where manager = 'Alice'

так как это обрабатывается самой базой данных автоматически и выглядит следующим образом

select * from departments

выданный Алисой, может получить только ее строки и ничьи больше.

Конечно, для того чтобы это работало, вы должны аутентифицировать/зарегистрировать пользователя любым способом, чтобы current_user стал «Алисой».

В Neon Authorize этот процесс идет на шаг дальше. Поскольку в настоящее время большинство приложений аутентифицируют пользователей с помощью JWT, этот JWT передается в Neon, который затем может использовать подтвержденную личность пользователя непосредственно в Postgres. Чтобы облегчить интеграцию с провайдером аутентификации, вам нужно добавить URL-адрес обнаружения JWT вашего провайдера в ваш проект Neon. Это позволит Neon получить необходимые ключи для проверки JWT:

Таким образом, когда ваш код вызывает:

const sql = neon(process. env. DATABASE_AUTHENTICATED_URL, { authToken: myAuthProvider. getJWT() });

Это позволяет получить идентификатор пользователя из токена, который расширение Neon с открытым исходным кодом pg_session_jwt делает доступным для Postgres для выполнения RLS.

Кроме того, вы также получите доступ к нескольким вспомогательным функциям, таким как auth. session() и auth.user_id(), которые помогут вам использовать JWT, поступающие от вашего провайдера аутентификации, например :

SELECT
u.name,
u.email
FROM
users u
WHERE
auth.user_id() = u.user_id

На момент написания статьи Neon Authorize совместим со следующими Auth-провайдерами:

• Clerk
• Stack Auth
• Auth0
• Stytch
• AWS Cognito
• Azure AD
• Descope Auth
• Supertokens
• Firebase Auth
• Keycloak
• GCP Cloud Identity

но этот список продолжает расширяться.

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

Вы можете запустить Neon локально или, если вы предпочитаете облачное управление, начать прямо сейчас с бесплатного предложения для 10 проектов и при необходимости обновить его позже. Также есть хороший учебник для начала работы, в котором в качестве провайдера аутентификации используется Clerk.