How to Integrate Lovable with Okta

Log in to your Okta Developer Console at developer.okta.com (for individual developers) or your-company.okta.com/admin (for enterprise accounts). In the left sidebar, navigate to Applications → Applications. Click 'Create App Integration'. In the sign-in method dialog, select 'OIDC - OpenID Connect'. For the application type, select 'Single-Page Application'. Click Next. On the new application configuration page: App integration name: Give it a descriptive name like 'Lovable Internal Dashboard'. Grant type: Check 'Authorization Code' and 'Refresh Token'. The PKCE (Proof Key for Code Exchange) option should be enabled by default for SPA applications. Sign-in redirect URIs: Add your deployed Lovable app URL followed by /login/callback (e.g., https://your-app.lovable.app/login/callback). Add http://localhost:3000/login/callback for local development if needed. Sign-out redirect URIs: Add your deployed app URL (e.g., https://your-app.lovable.app). Controlled access: For development, select 'Allow everyone in your organization to access'. For production, you may want to restrict to specific Okta groups. Save the application. After saving, you will see the Client ID on the application's General tab. Copy it. Also note your Okta domain from the browser URL bar or from Security → API → Authorization Servers — the issuer URL follows the format https://your-domain.okta.com/oauth2/default or https://your-domain.okta.com/oauth2/{authorization-server-id}. If you need Okta groups passed as claims in the JWT (for role-based access control), go to Security → API → Authorization Servers → default → Claims. Add a new claim named 'groups', with value type 'Groups', filter 'Matches regex .*' to include all groups, and include it in the 'Access Token'. This makes Okta group memberships available in the JWT your Edge Functions will read.

Store your Okta application's connection details in Lovable's Cloud Secrets panel. While the Okta domain and Client ID are not secret in the same way an API key is (they are embedded in the frontend SDK configuration), centralizing them in Secrets makes your configuration easier to manage across environments and allows the Edge Function JWT validation to access them without hardcoding. Click the '+' icon next to the Preview label in the Lovable editor to open the Cloud panel. Click the 'Secrets' tab and add the following secrets: - Name: OKTA_ISSUER — Value: your Okta authorization server issuer URL (e.g., https://dev-12345.okta.com/oauth2/default or https://your-company.okta.com/oauth2/default). This must be the full URL including /oauth2/default or your custom authorization server ID. - Name: OKTA_CLIENT_ID — Value: your Okta application's Client ID (from the application's General tab) - Name: OKTA_AUDIENCE — Value: 'api://default' for the default authorization server, or your custom audience identifier if you configured one The Issuer is the most critical value for Edge Function JWT validation — it is used to fetch the JWKS endpoint at {OKTA_ISSUER}/v1/keys and to verify the issuer claim in incoming JWTs. If this value is wrong, all JWT validation will fail with an issuer mismatch error. For Okta on the okta.com domain, the issuer format is https://your-domain.okta.com/oauth2/default. For Okta on custom domains, it may be https://auth.your-company.com/oauth2/default. Check Security → API → Authorization Servers in the Okta console for the exact value.

The Okta Auth JS SDK (@okta/okta-auth-js) and its React wrapper (@okta/okta-react) handle the OIDC authorization code flow with PKCE in your browser, including the login redirect, token exchange, token storage, and token refresh. These packages are installed as npm dependencies in your Lovable project. To add Okta to your Lovable frontend, open the chat panel and describe the authentication flow you need. Lovable will add the packages to package.json and generate the Security component and route configuration. The Okta React SDK provides a Security wrapper component (similar to Auth0Provider), a LoginCallback component for handling the redirect, and hooks including useOktaAuth for accessing the auth state and access tokens in any component. The authState object from useOktaAuth includes isAuthenticated, isPending, and idToken with the user's profile information. For displaying user information after login, useOktaAuth().authState.idToken.claims contains the user's sub (unique ID), email, name, and any custom claims including the groups claim if you configured it in Step 1. Map these to your UI components and Supabase queries.

1// src/main.tsx — Okta Security provider setup
2import { OktaAuth } from '@okta/okta-auth-js';
3import { Security } from '@okta/okta-react';
4import { useNavigate } from 'react-router-dom';
5
6const oktaAuth = new OktaAuth({
7  issuer: import.meta.env.VITE_OKTA_ISSUER || 'https://your-domain.okta.com/oauth2/default',
8  clientId: import.meta.env.VITE_OKTA_CLIENT_ID || 'your-client-id',
9  redirectUri: `${window.location.origin}/login/callback`,
10  scopes: ['openid', 'profile', 'email', 'offline_access'],
11  pkce: true,
12});
13
14function AppWithOkta() {
15  const navigate = useNavigate();
16  const restoreOriginalUri = async (_oktaAuth: OktaAuth, originalUri: string) => {
17    navigate(originalUri ?? '/');
18  };
19  return (
20    <Security oktaAuth={oktaAuth} restoreOriginalUri={restoreOriginalUri}>
21      <App />
22    </Security>
23  );
24}
25
26ReactDOM.createRoot(document.getElementById('root')!).render(
27  <BrowserRouter>
28    <AppWithOkta />
29  </BrowserRouter>
30);

Supabase Edge Functions that serve protected data must validate the Okta JWT from the Authorization header before executing any database queries. Okta uses RS256 JWT signing (like Auth0), so validation requires fetching Okta's public keys from the JWKS endpoint at {OKTA_ISSUER}/v1/keys. The Edge Function below validates the Okta access token, extracts the user's Okta user ID and groups, and uses the groups to implement role-based access control before querying Supabase. This implements the common enterprise pattern where IT defines access through Okta group membership rather than application-level role assignment. For an internal dashboard, you might have groups like 'dashboard-viewers' (read access) and 'dashboard-admins' (read and write access). IT assigns employees to these groups in the Okta admin console, and your Edge Function enforces the authorization without requiring any changes to the Lovable application. Note that Okta access tokens (as opposed to ID tokens) contain the groups claim if you configured it in Step 1. Make sure you are passing the access token (obtained via oktaAuth.getAccessToken()) to the Edge Function, not the ID token.

1// supabase/functions/okta-protected/index.ts
2import { createRemoteJWKSet, jwtVerify } from 'https://esm.sh/jose@5';
3import { createClient } from 'https://esm.sh/@supabase/supabase-js@2';
4
5const corsHeaders = {
6  'Access-Control-Allow-Origin': '*',
7  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
8};
9
10Deno.serve(async (req) => {
11  if (req.method === 'OPTIONS') return new Response('ok', { headers: corsHeaders });
12
13  const authHeader = req.headers.get('Authorization');
14  if (!authHeader?.startsWith('Bearer ')) {
15    return new Response(JSON.stringify({ error: 'Authentication required' }), {
16      status: 401,
17      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
18    });
19  }
20
21  const token = authHeader.replace('Bearer ', '');
22  const issuer = Deno.env.get('OKTA_ISSUER')!;
23  const audience = Deno.env.get('OKTA_AUDIENCE') || 'api://default';
24
25  try {
26    const JWKS = createRemoteJWKSet(new URL(`${issuer}/v1/keys`));
27
28    const { payload } = await jwtVerify(token, JWKS, {
29      issuer,
30      audience,
31    });
32
33    const userId = payload.sub as string;
34    const groups = (payload.groups as string[]) ?? [];
35
36    // Role-based access: require membership in the dashboard-viewers group
37    if (!groups.includes('dashboard-viewers') && !groups.includes('dashboard-admins')) {
38      return new Response(JSON.stringify({ error: 'Insufficient permissions. Contact IT to request dashboard access.' }), {
39        status: 403,
40        headers: { ...corsHeaders, 'Content-Type': 'application/json' },
41      });
42    }
43
44    const isAdmin = groups.includes('dashboard-admins');
45
46    const supabase = createClient(
47      Deno.env.get('SUPABASE_URL')!,
48      Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
49    );
50
51    const { data, error } = await supabase
52      .from('dashboard_metrics')
53      .select(isAdmin ? '*' : 'id, name, public_value')
54      .order('created_at', { ascending: false })
55      .limit(50);
56
57    if (error) throw error;
58
59    return new Response(JSON.stringify({ data, userId, isAdmin }), {
60      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
61    });
62  } catch (err) {
63    console.error('Okta JWT error:', err);
64    return new Response(JSON.stringify({ error: 'Invalid or expired token' }), {
65      status: 401,
66      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
67    });
68  }
69});

Okta authentication must be tested on your deployed Lovable app URL, not in the Lovable editor preview. The OIDC redirect flow requires your app to be running on exactly the URL registered in Okta's Sign-in redirect URIs configuration. Deploy your app by clicking the Publish button in the top-right corner of the Lovable editor. Once deployed, open the live URL in a new browser tab. Click the login button. You should be redirected to your Okta login page — either the Okta-hosted login at your-domain.okta.com/login or your organization's custom Okta login page if configured. Enter your Okta credentials (username and password, plus MFA if configured). After successful authentication, Okta redirects back to your app at /login/callback with an authorization code. The Okta React SDK exchanges this for access and ID tokens. You should be redirected to your dashboard with the user's name and email displayed. To test group-based access control, create test users in Okta assigned to different groups and verify the Edge Function returns data for members of the required group and 403 for users in other groups. When your team is ready to use the app, share the deployed URL with employees. They can bookmark it and use their Okta credentials to log in. For enterprise accounts, you can also add the Lovable app to the Okta App Catalog so employees see it as a tile in their Okta dashboard — this requires registering your app as an Okta bookmark app or SAML/OIDC integration in the Okta admin console.

1// src/hooks/useOktaProtectedData.ts
2import { useOktaAuth } from '@okta/okta-react';
3import { useState, useEffect } from 'react';
4import { supabase } from '@/integrations/supabase/client';
5
6export function useOktaProtectedData() {
7  const { oktaAuth, authState } = useOktaAuth();
8  const [data, setData] = useState(null);
9  const [isAdmin, setIsAdmin] = useState(false);
10  const [accessError, setAccessError] = useState<string | null>(null);
11  const [loading, setLoading] = useState(false);
12
13  useEffect(() => {
14    if (!authState?.isAuthenticated) return;
15    const fetchData = async () => {
16      setLoading(true);
17      try {
18        const accessToken = await oktaAuth.getAccessToken();
19        const { data: result, error } = await supabase.functions.invoke('okta-protected', {
20          headers: { Authorization: `Bearer ${accessToken}` },
21        });
22        if (error?.message?.includes('403')) {
23          setAccessError('Contact IT to request dashboard access in Okta.');
24          return;
25        }
26        if (error) throw error;
27        setData(result.data);
28        setIsAdmin(result.isAdmin);
29      } catch (err) {
30        console.error('Dashboard data error:', err);
31      } finally {
32        setLoading(false);
33      }
34    };
35    fetchData();
36  }, [authState?.isAuthenticated]);
37
38  return { data, isAdmin, accessError, loading };
39}