[Logto](https://logto.io/) — это современный провайдер услуг аутентификации личности, который предлагает безопасную, комплексную и удобную поддержку входа в приложения. Он также предоставляет множество SDK и руководств по интеграции для различных фреймворков и языков программирования, что позволяет вам беспрепятственно интегрировать корпоративные услуги аутентификации в ваше приложение в считанные минуты. Эта статья главным образом сосредоточена на том, как интегрировать Supabase с Logto. ## Основы Supabase Supabase использует [Многоуровневую безопасность на уровне строк Postgres](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) для управления доступом к данным. Проще говоря, создавая политики безопасности на уровне строк для таблиц в базе данных, мы можем ограничивать и управлять доступом каждого пользователя к чтению, записи и обновлению данных в таблице. Предположим, у вас есть таблица под названием "posts" в вашей базе данных со следующим содержимым: Таблица постов

Поле `user_id` в таблице представляет пользователя, которому принадлежат данные каждого поста. Вы можете ограничить каждого пользователя доступом только к своим данным постов на основе поля `user_id`. Однако, прежде чем это может быть реализовано, Supabase должно идентифицировать текущего пользователя, который обращается к базе данных. ### Добавление пользовательских данных в запросы к Supabase Благодаря поддержке JWT в Supabase, когда наше приложение взаимодействует с Supabase, мы можем сгенерировать JWT, содержащий данные пользователя, используя секрет JWT, предоставленный Supabase. Затем мы используем этот JWT в качестве заголовка Authentication при отправке запросов. После получения запроса Supabase автоматически проверяет действительность JWT и предоставляется доступ к данным внутри JWT на протяжении всех последующих процессов. Сначала мы можем получить секрет JWT, предоставленный Supabase, в "Настройки проекта" на панели управления Supabase: Страница настроек API Supabase

Затем, при использовании SDK Supabase для отправки запросов в Supabase, мы используем этот секрет для генерации нашего JWT и прикрепляем его в качестве заголовка Authentication к запросу. (Обратите внимание, что этот процесс происходит в сервисе вашего приложения на стороне сервера, и секрет JWT никогда не должен быть раскрыт третьим лицам). ```jsx import { createClient } from '@supabase/supabase-js'; import { sign } from 'jsonwebtoken'; / * Примечание: * Вы можете найти SUPABASE_URL, SUPABASE_ANON_KEY в том же месте, где и секрет JWT. */ const SUPABASE_URL = process.env.SUPABASE_URL; const SUPABASE_ANON_KEY = process.env.SUPABASE_ANON_KEY; const SUPABASE_JWT_SECRET = process.env.SUPABASE_JWT_SECRET; export const getSupabaseClient = (userId) => { const jwtPayload = { userId, }; const jwt = sign(jwtPayload, SUPABASE_JWT_SECRET, { expiresIn: '1h', // Просто для демонстрации }); const client = createClient(SUPABASE_URL, SUPABASE_ANON_KEY, { global: { headers: { Authorization: `Bearer ${jwt}`, }, }, }); return client; }; ``` Далее перейдите в SQL Editor на панели управления Supabase и создайте функцию для получения userId, переданного в запросе: Создание функции получения идентификатора пользователя

Создание функции получения идентификатора пользователя

Код, использованный на изображении, выглядит следующим образом: ```sql create or replace function auth.user_id() returns text as $$ select nullif(current_setting('request.jwt.claims', true)::json->>'userId', '')::text; $$ language sql stable; ``` Как показано в коде, в Supabase можно получить payload JWT, который мы генерируем, вызвав `request.jwt.claims`. Поле `userId` внутри payload — это значение, которое мы задали. С помощью этой функции Supabase может определить, какой пользователь в настоящее время обращается к базе данных. ### Создание политики на уровне строк Затем мы можем создать политику на уровне строк, чтобы ограничить каждого пользователя доступом только к своим данным постов на основе поля `user_id` в таблице постов. 1. Перейдите на страницу Table Editor на панели управления Supabase и выберите таблицу posts. 2. Нажмите на "Add RLS Policy" в верхней части таблицы. 3. В появившемся окне нажмите "Create policy". 4. Введите название политики и выберите команду SELECT Policy. 5. В блоке `using` кода ниже введите: ```sql auth.user_id() = user_id ``` Создание политики на уровне строк

Используя такие политики, можно эффективно контролировать доступ к данным внутри Supabase. В реальных приложениях вы можете создать различные политики для ограничения действий пользователей, таких как добавление или изменение данных. Однако это выходит за рамки данной статьи. Для получения дополнительной информации о политике на уровне строк (RLS) обратитесь к [Защите ваших данных с помощью Postgres Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security). ### Основной процесс интеграции с Logto Как упоминалось ранее, поскольку Supabase использует RLS для контроля доступа, ключ к интеграции с Logto (или любым другим сервисом аутентификации) заключается в получении идентификатора пользователя и его отправке в Supabase. Весь процесс показан на диаграмме ниже: ```mermaid sequenceDiagram Participant U as Конечный пользователь Participant Logto Participant B as Бэкенд сервис приложения Participant Supabase U->>Logto: Авторизация через Logto Logto-->>U: `access_token` U->>B: Запрос данных с `access_token` B->>B: Получение `user_id` из `access_token` B->>B: Генерация JWT с `user_id` и секретом JWT Supabase B->>Supabase: Запрос данных с JWT Supabase-->>B: Возвращенные данные B-->>U: Возвращенные данные ``` Теперь мы объясним, как интегрировать Logto с Supabase на основе этой процессной диаграммы. ## Интеграция Logto Logto предлагает руководства по интеграции для различных фреймворков и языков программирования. Обычно приложения, созданные с использованием этих фреймворков и языков, можно отнести к следующим категориям: нативные приложения, SPA (одностраничные приложения), традиционные веб-приложения и M2M (приложения «машина-машина»). Вы можете перейти на страницу [Logto Quick Start](https://docs.logto.io/quick-starts/), чтобы интегрировать Logto в свое приложение на основе используемой вами технологической платформы. После этого следуйте инструкциям ниже, чтобы интегрировать Logto в ваш проект в зависимости от типа вашего приложения. ### Нативное приложение или SPA И нативные приложения, и SPA выполняются на вашем устройстве, и учетные данные (токен доступа), полученные после входа в систему, хранятся локально на вашем устройстве. Следовательно, при интеграции вашего приложения с Supabase вам нужно взаимодействовать с Supabase через ваш бэкенд-сервис, так как вы не можете раскрывать конфиденциальную информацию (например, секрет JWT Supabase) на каждом устройстве пользователя. Допустим, вы создаете свое SPA с использованием React и Express. Вы успешно интегрировали Logto в ваше приложение, следуя [Руководству по Logto React SDK](https://docs.logto.io/quick-starts/react/) (вы можете ознакомиться с кодом в нашем [React sample](https://github.com/logto-io/js/tree/master/packages/react-sample)). Кроме того, вы добавили проверку токена доступа Logto в ваш серверный API в соответствии с документацией [Защита вашего API в Node (Express)](https://docs.logto.io/docs/recipes/protect-your-api/node/). Далее вы будете использовать токен доступа, полученный от Logto, для запроса пользовательских данных с вашего серверного API: ```jsx import { useLogto } from '@logto/react'; import { useState, useEffect } from 'react'; import PostList from './PostList'; const endpoint = ''; const resource = ''; function PostPage() { const { isAuthenticated, getAccessToken } = useLogto(); const [posts, setPosts] = useState(); useEffect(() => { const fetchPosts = async () => { const response = await fetch(endpoint, { headers: { Authorization: `Bearer ${await getAccessToken(resource)}`, }, }); setPosts(response.json()); }; if (isAuthenticated) { void fetchPosts(); } }, [isAuthenticated, getAccessToken]); return ; } export default PostPage; ``` На вашем сервере backend вы уже извлекли идентификатор вошедшего пользователя из access token с помощью middleware: ```jsx // auth-middleware.ts import { createRemoteJWKSet, jwtVerify } from 'jose'; //... export const verifyAuthFromRequest = async (ctx, next) => { // Извлечение токена const token = extractBearerTokenFromHeaders(ctx.request.headers); const { payload } = await jwtVerify( token, // Сырой токен Bearer, извлеченный из заголовка запроса createRemoteJWKSet(new URL('https:///oidc/jwks')), // генерация jwks с использованием jwks_uri, запрашиваемого на сервере Logto { // ожидаемый издатель токена, должен быть выдан сервером Logto issuer: 'https:///oidc', // ожидаемая аудитория токена, должна быть индикатором ресурса текущего API audience: '', } ); // если вы используете RBAC assert(payload.scope.includes('some_scope')); // пользовательская логика payload ctx.auth = { userId: payload.sub, }; return next(); }; ``` Теперь вы можете использовать `getSupabaseClient`, описанный выше, чтобы прикрепить `userId` к JWT, используемому в последующих запросах к Supabase. Либо вы можете создать middleware для создания клиента Supabase для тех запросов, которые должны взаимодействовать с Supabase: ```jsx export const withSupabaseClient = async (ctx, next) => { ctx.supabase = getSupabaseClient(ctx.auth.userId); return next(); }; ``` В последующем процессе вы можете напрямую вызывать `ctx.supabase` для взаимодействия с Supabase: ```jsx const fetchPosts = async (ctx) => { cosnt { data } = await ctx.supabase.from('posts').select('*'); return data; } ``` В этом коде Supabase вернет данные постов, принадлежащие только текущему пользователю, на основе ранее установленных политик. ### Традиционное веб-приложение Главное различие между традиционным веб-приложением и нативным приложением или SPA заключается в том, что традиционное веб-приложение рендерит и обновляет страницы исключительно на веб-сервере. Следовательно, учетные данные пользователей управляются непосредственно веб-сервером, тогда как в нативных приложениях и SPA они находятся на устройстве пользователя. При интеграции Logto с традиционным веб-приложением в Supabase вы можете напрямую извлечь идентификатор вошедшего пользователя из бэкэнда. Взяв за пример проект на Next.js, после интеграции Logto в ваш проект, следуя [Руководству по Next.js SDK](https://docs.logto.io/quick-starts/next-app-router/), вы можете использовать SDK Logto для получения информации о пользователе и построения соответствующего JWT для взаимодействия с Supabase. ```jsx import { getLogtoContext } from '@logto/next-server-actions'; import { logtoConfig } from '@/logto'; import { getSupabaseClient } from '@/utils'; import PostList from './PostList'; export default async function PostPage() { const { cliams } = await getLogtoContext(logtoConfig); // Значение `sub` в `cliams` — это идентификатор пользователя. const supabase = getSupabaseClient(cliams.sub); const { data: posts } = await supabase.from('posts').select('*'); return ; } ``` ### Приложение «машина-машина» Связь типа «машина-машина» (M2M) часто используется, когда вашему приложению необходимо напрямую взаимодействовать с серверами ресурсов, например, статическим сервисом, который ежедневно собирает посты и т.д. Вы можете использовать руководство [Machine-to-machine: Auth with Logto](https://docs.logto.io/quick-starts/m2m/), чтобы установить аутентификацию приложения «машина-машина». Интеграция Supabase с приложениями типа «машина-машина» схожа с интеграцией нативных приложений и SPA (как описано в разделе "Нативное приложение или одностраничное приложение"). Это предполагает получение токена доступа от Logto, а затем его проверку с помощью защищенного бэкэнд API. Однако важно отметить, что приложения типа нативных и SPA обычно предназначены для конечных пользователей, поэтому идентификатор пользователя, получаемый в этих приложениях, представляет самого пользователя. Однако токен доступа для приложений типа "машина-машина" представляет само приложение, и поле `sub` в payload токена доступа является идентификатором клиента M2M приложения, а не конкретного пользователя. Поэтому при разработке важно разграничивать данные, предназначенные для приложений типа "машина-машина". Более того, если вы хотите, чтобы конкретное приложение "машина-машина" получало доступ к Supabase от имени всего сервиса, обходя ограничения RLS, вы можете использовать секрет `service_role` Supabase для создания клиента Supabase. Это полезно, когда вы хотите реализовать административные или автоматические задачи, требующие доступа ко всем данным без ограничений, установленных политиками безопасности на уровне строк для отдельных пользователей. Секрет `service_role` можно найти на той же странице, что и секрет JWT: Секрет service role

При создании клиента Supabase используйте секрет `service_role`, и этот клиент сможет получить доступ ко всем данным в базе данных: ```jsx import { createClient } from '@supabase/supabase-js'; // ... const SUPABASE_SERVICE_ROLE_SCRET = process.env.SUPABASE_SERVICE_ROLE_SCRET; const client = createClient(SUPABASE_URL, SUPABASE_SERVICE_ROLE_SCRET, { // ...опции }); ``` ## Резюме В этой статье мы подробно обсудили интеграцию Logto с Supabase, осветив ключевые аспекты и важные элементы интеграции. Мы рассмотрели такие концепции, как аутентификация с использованием JWT и политики безопасности на уровне строк, руководствуясь процессом беспрепятственной интеграции Logto в приложения, использующие Supabase. С этими знаниями мы надеемся, что вы сможете уверенно повысить безопасность вашего приложения, расширить его функциональность и даже дополнить проекты новыми функциями.