[Logto](https://logto.io/) is een moderne identiteitsauthenticatie-serviceprovider die veilige, uitgebreide en gebruiksvriendelijke login-ondersteuning voor applicaties biedt. Het biedt ook veel SDK's en integratiegidsen voor meerdere frameworks en programmeertalen, waarmee je binnen enkele minuten naadloos bedrijfswaardige identiteitsauthenticatiediensten in je applicatie kunt integreren. Dit artikel richt zich voornamelijk op het detailleren van hoe je Supabase met Logto kunt integreren. ## Supabase basisprincipes Supabase maakt gebruik van [Postgres's Row-Level Security](https://www.postgresql.org/docs/current/ddl-rowsecurity.html) om gegevenstoegangsrechten te beheren. Simpel gezegd, door Row Level Security-beleidsregels voor tabellen in de database te maken, kunnen we beperken en beheren wie gegevens in een tabel kan lezen, schrijven en bijwerken. Laten we aannemen dat je een tabel genaamd "posts" in je database hebt, met de volgende inhoud: Posts-tabel

Het `user_id`-veld in de tabel vertegenwoordigt de gebruiker waartoe elke post behoort. Je kunt elke gebruiker beperken tot alleen toegang tot hun eigen post-gegevens op basis van het `user_id`-veld. Voordat dit echter kan worden geïmplementeerd, moet Supabase de huidige gebruiker kunnen identificeren die toegang krijgt tot de database. ### Voeg gebruikersgegevens toe aan de Supabase-verzoeken Dankzij de ondersteuning van Supabase voor JWT, kunnen we, wanneer onze applicatie met Supabase communiceert, een JWT genereren die gebruikersgegevens bevat met het door Supabase verstrekte JWT-geheim. We gebruiken deze JWT vervolgens als de Authentication-header bij het indienen van verzoeken. Na het ontvangen van het verzoek verifieert Supabase automatisch de geldigheid van de JWT en geeft toegang tot de gegevens die erin zijn opgenomen gedurende de daaropvolgende processen. Ten eerste kunnen we het door Supabase verstrekte JWT-geheim verkrijgen via de "Project Settings" in het Supabase-dashboard: Supabase API-instellingen pagina

Vervolgens gebruiken we, wanneer we het Supabase SDK gebruiken om verzoeken naar Supabase te sturen, dit geheim om onze JWT te genereren en het als de Authentication-header aan het verzoek toe te voegen. (Houd er rekening mee dat dit proces plaatsvindt binnen de backend-service van je applicatie en dat het JWT-geheim nooit aan derden mag worden blootgesteld). ```jsx import { createClient } from '@supabase/supabase-js'; import { sign } from 'jsonwebtoken'; / * Opmerking: * Je kunt de SUPABASE_URL, SUPABASE_ANON_KEY vinden op dezelfde plaats waar je het JWT Secret vindt. */ 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', // Alleen voor demonstratie }); const client = createClient(SUPABASE_URL, SUPABASE_ANON_KEY, { global: { headers: { Authorization: `Bearer ${jwt}`, }, }, }); return client; }; ``` Navigeer vervolgens naar de SQL Editor in het Supabase-dashboard en maak een functie om de userId op te halen die in het verzoek is opgenomen: Maak functie voor het ophalen van gebruikers-ID

Maak functie voor het ophalen van gebruikers-ID

De in de afbeelding gebruikte code is als volgt: ```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; ``` Zoals de code laat zien, kun je in Supabase de payload van de JWT die we genereren ophalen door `request.jwt.claims` aan te roepen. Het `userId`-veld binnen de payload is de waarde die we hebben ingesteld. Met deze functie kan Supabase bepalen welke gebruiker momenteel toegang heeft tot de database. ### Maak Row-Level Security beleidsregel Vervolgens kunnen we een Row-Level Security beleidsregel maken om elke gebruiker te beperken tot alleen toegang tot hun eigen post-gegevens op basis van het `user_id`-veld in de posts-tabel. 1. Ga naar de Table Editor-pagina in het Supabase-dashboard en selecteer de posts-tabel. 2. Klik bovenaan de tabel op "Add RLS Policy". 3. Klik in het weergegeven venster op "Create policy". 4. Voer een beleidsnaam in en kies de SELECT beleidsopdracht. 5. Voer in het `using`-blok van de onderstaande code in: ```sql auth.user_id() = user_id ``` Maak RLS-beleidsregel

Door gebruik te maken van dergelijke beleidsregels, wordt gegevenscontrole binnen Supabase bereikt. In toepassingen in de echte wereld zou je verschillende beleidsregels maken om gebruikersacties zoals het invoegen en wijzigen van gegevens te beperken. Dit valt echter buiten de reikwijdte van dit artikel. Voor meer informatie over Row-Level Security (RLS), verwijzen we naar [Beveilig je data met Postgres Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security). ### Basisintegratieproces met Logto Zoals eerder vermeld, omdat Supabase RLS gebruikt voor zijn toegangscontrole, ligt de sleutel tot integratie met Logto (of andere authenticatieservices) in het verkrijgen van de gebruikers-ID van de gemachtigde gebruiker en het verzenden naar Supabase. Het hele proces wordt geïllustreerd in het onderstaande diagram: ```mermaid sequenceDiagram Participant U as Eindgebruiker Participant Logto Participant B as App backend service Participant Supabase U->>Logto: Log in met Logto Logto-->>U: `access_token` U->>B: Verzoek gegevens met `access_token` B->>B: Haal `user_id` uit `access_token` B->>B: Genereer jwt door `user_id` & `Supabase JWT secret` B->>Supabase: Verzoek gegevens met jwt Supabase-->>B: Geantwoord gegevens B-->>U: Geantwoord gegevens ``` Vervolgens leggen we uit hoe je Logto met Supabase kunt integreren op basis van dit procesdiagram. ## Logto-integratie Logto biedt integratiegidsen voor verschillende frameworks en programmeertalen. Over het algemeen vallen apps die met deze frameworks en talen zijn gebouwd in categorieën zoals native apps, SPA (single-page apps), traditionele webapps en M2M (machine-to-machine) apps. Je kunt de [Logto quick starts](https://docs.logto.io/quick-starts/) pagina bezoeken om Logto in je applicatie te integreren op basis van de tech-stack die je gebruikt. Volg daarna de onderstaande instructies om Logto in je project te integreren op basis van het type toepassing. ### Native app of SPA Zowel native apps als SPA's draaien op je apparaat, en de inloggegevens (access token) die na het inloggen worden verkregen, worden lokaal op je apparaat opgeslagen. Daarom moet je, wanneer je je app integreert met Supabase, communiceren met Supabase via je backend-service omdat je gevoelige informatie (zoals Supabase JWT secret) niet op elk apparaat van de gebruiker kunt blootstellen. Laten we aannemen dat je je SPA bouwt met React en Express. Je hebt Logto met succes geïntegreerd in je applicatie door de [Logto React SDK Guide](https://docs.logto.io/quick-starts/react/) te volgen (je kunt refereren aan de code in ons [react sample](https://github.com/logto-io/js/tree/master/packages/react-sample)). Daarnaast heb je Logto-toegangstokenvalidatie toegevoegd aan je backend-server volgens de [Bescherm je API op Node (Express)](https://docs.logto.io/docs/recipes/protect-your-api/node/) documentatie. Vervolgens gebruik je het toegangstoken dat je van Logto hebt verkregen om gebruikersgegevens op te vragen bij je backend-server: ```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; ``` Op je backend-server heb je al de id van de ingelogde gebruiker uit het toegangstoken gehaald met behulp van middleware: ```jsx // auth-middleware.ts import { createRemoteJWKSet, jwtVerify } from 'jose'; //... export const verifyAuthFromRequest = async (ctx, next) => { // Haal de token uit const token = extractBearerTokenFromHeaders(ctx.request.headers); const { payload } = await jwtVerify( token, // De rauwe Bearer Token gehaald uit de aanvraagheader createRemoteJWKSet(new URL('https:///oidc/jwks')), // genereer een jwks met behulp van jwks_uri gehaald van Logto server { // Verwachte verstrekker van de token, zou door de Logto server moeten worden verstrekt issuer: 'https:///oidc', // Verwachte doelgroep-token, zou de resource-indicator van de huidige API moeten zijn audience: '', } ); // Als je RBAC gebruikt assert(payload.scope.includes('some_scope')); // aangepaste payloadlogica ctx.auth = { userId: payload.sub, }; return next(); }; ``` Nu kun je de `getSupabaseClient` gebruiken, zoals hierboven beschreven, om de `userId` bij de JWT te voegen die in volgende verzoeken aan Supabase wordt gebruikt. Je kunt ook een middleware maken om een Supabase-client te maken voor verzoeken die met Supabase moeten communiceren: ```jsx export const withSupabaseClient = async (ctx, next) => { ctx.supabase = getSupabaseClient(ctx.auth.userId); return next(); }; ``` In de daaropvolgende verwerkingsstroom kun je `ctx.supabase` rechtstreeks aanroepen om met Supabase te communiceren: ```jsx const fetchPosts = async (ctx) => { const { data } = await ctx.supabase.from('posts').select('*'); return data; } ``` In deze code geeft Supabase alleen de post-gegevens terug die behoren tot de huidige gebruiker op basis van de eerder ingestelde beleidsregels. ### Traditionele webapp Het belangrijkste verschil tussen een traditionele webapp en een native app of SPA is dat een traditionele webapp pagina's uitsluitend op de webserver weergeeft en bijwerkt. Daarom worden gebruikersgegevens direct door de webserver beheerd, terwijl ze in native apps en SPA's zich op het apparaat van de gebruiker bevinden. Bij het integreren van Logto met een traditionele webapp in Supabase kun je direct de id van de ingelogde gebruiker van de backend ophalen. Neem een Next.js-project als voorbeeld, nadat je Logto met je project hebt geïntegreerd volgens de [Next.js SDK Guide](https://docs.logto.io/quick-starts/next-app-router/), kun je de Logto SDK gebruiken om gebruikersinformatie op te halen en de overeenkomstige JWT te construeren voor interactie met 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` waarde in `cliams` is gebruikers-ID. const supabase = getSupabaseClient(cliams.sub); const { data: posts } = await supabase.from('posts').select('*'); return ; } ``` ### Machine-to-machine app Machine-to-machine (M2M) wordt vaak gebruikt wanneer je app direct moet communiceren met recourceservers, zoals een statische service die dagelijkse posts ophaalt, enz. Je kunt de [Machine-to-machine: Auth with Logto](https://docs.logto.io/quick-starts/m2m/) gids gebruiken voor authenticatie van machine-to-machine apps. De integratie tussen Supabase en machine-to-machine-apps lijkt op die van native apps en SPA's (zoals beschreven in de "Native app of single-page app"-sectie). Het omvat het verkrijgen van een toegangstoken van Logto en het valideren ervan via een beveiligde backend-API. Het is echter belangrijk op te merken dat native apps en SPA's doorgaans zijn ontworpen voor eindgebruikers, dus de verkregen user-id vertegenwoordigt de gebruiker zelf. Het toegangstoken voor machine-to-machine apps vertegenwoordigt echter de applicatie zelf, en het `sub`-veld in de toegangstoken payload is de client-id van de M2M-app, niet een specifieke gebruiker. Daarom is het tijdens de ontwikkeling cruciaal om onderscheid te maken welke gegevens bestemd zijn voor M2M-apps. Verder, als je wilt dat een specifieke M2M-app toegang heeft tot Supabase namens de hele service om RLS-beperkingen te omzeilen, kun je de `service_role` geheim van Supabase gebruiken om een Supabase-client te maken. Dit is handig wanneer je enkele administratieve of geautomatiseerde taken wilt uitvoeren die toegang vereisen tot alle gegevens zonder beperkt te worden door de Row-Level Security beleidsregels die zijn ingesteld voor individuele gebruikers. Het `service_role` geheim kan worden gevonden op dezelfde pagina als het JWT-geheim: Service rol geheim

Bij het maken van een Supabase-client gebruik je het `service_role` geheim, dan kan deze client toegang krijgen tot alle gegevens in de database: ```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, { // ...opties }); ``` ## Samenvatting In dit artikel gaan we dieper in op het integreren van Logto met Supabase, waarbij we belangrijke inzichten en kritieke integratieaspecten belichten. We verkennen concepten zoals JWT-authenticatie en Row-Level Security beleidsregels, en leiden je door het proces van het naadloos opnemen van Logto in je Supabase-aangedreven applicaties. Met deze kennis hopen we dat je vol vertrouwen de beveiliging en functionaliteit van je applicatie kunt verbeteren, en zelfs je projecten kunt uitbreiden met extra functies.