OpenID Connect (Authentication System)

OpenID Connect lets you connect WeWeb to an identity provider that supports OIDC (for example Okta, Azure AD, or Keycloak).

What this system supports

• Redirect-based sign in
• Optional scopes (defaults to openid profile email)
• A choice of where sign in tokens are kept in the browser (Local storage (default) or Memory)

Set up your identity provider

In your provider dashboard:

1. Create an OpenID Connect application.
2. Add allowed URLs for each environment (preview, staging, production) so redirects work.
3. Copy the values you need:
   • Issuer URL
   • Client ID
   • (Optional) scopes you want to request

Connect OpenID Connect in WeWeb

1. Open the Data & API tab, then open the Authentication subtab.
2. • A) If this is your first time opening the Authentication area, choose OpenID Connect when prompted.
   • B) If this is not your first time, open the Settings tab, expand Switch Authentication Provider, and click Switch Authentication, then select OpenID Connect.
3. Create/select a Connection (per environment).
4. Fill:
   • Issuer URL
   • Client ID
   • Scopes (Optional)
   • Browser token storage (Optional, set to Local storage (default) unless you change it)

Browser token storage

When someone signs in, the browser needs to keep the tokens that prove they are logged in. The Browser token storage field lets you choose where those tokens live:

• Local storage (default) Keeps them in the browser’s local storage. People stay signed in after a reload and in other tabs. Connections that were created before this option existed keep behaving exactly this way.
• Memory Keeps them in the current page only. Nothing is written to local storage, session storage, or cookies.

Pick Memory when a security review asks you to avoid leaving tokens somewhere a script running in the page could read them later. Sign in, token renewal, and sign out all keep working the same way.

WARNING

With Memory, tokens disappear on a full reload and are not shared with other tabs, so people may need to sign in again. Selecting Memory also deletes the tokens already stored locally for that connection. This option reduces how long tokens stay in the browser, it does not protect you from cross-site scripting (code injected into your own page).

INFO

If the WeWeb backend is enabled on your project, it keeps its own session in a secure HttpOnly cookie. That cookie is managed by the server, cannot be read by scripts in the page, and is not affected by Browser token storage.

Test sign in

1. Add a login flow in the Interface tab using the OpenID Connect actions.
2. Preview and sign in.
3. Confirm the user is authenticated and protected content behaves as expected.

For page and API protection, see Users and roles →.

Common pitfalls

Redirect URI mismatch

If the provider shows a redirect error, the allowed redirect URL in the provider dashboard does not match the environment URL you are testing on. Copy the exact URL from your browser and add it to the provider’s allowed redirect URLs.

Users have to sign in again after a reload

If Browser token storage is set to Memory, the tokens only live in the current page. Reloading the page or opening the app in a new tab signs the person out. Switch back to Local storage (default) if you need the session to survive a reload.

Missing email

Some providers do not return an email address unless you request the right scope. If you need email, include email in Scopes.

Reference

Connection fields

Field	Description
Issuer URL	Provider URL used for discovery (via /.well-known/openid-configuration)
Client ID	Client ID for your OIDC application
Scopes	Space-separated scopes (default: openid profile email)
Browser token storage	Where sign in tokens are kept in the browser: Local storage (default) or Memory