Authentication Integration
WEDA uses a shared cookie architecture for browser-based authentication. Rather than each application managing its own identity flow, WEDA delegates authentication to the Portal — a single entry point that handles login, logout, and tenant switching on behalf of all connected systems (SRP — Shared Resource Platform).
This page covers what a frontend developer needs to know when building a web app on top of WEDA.
If you need a bearer token for WEDA API calls, see Authentication — that page covers the SSO 5-step flow and M2M Client Credentials. This page explains the browser cookie layer that sits underneath it.
The AdvOidc.Login Cookie
After a successful login, Portal issues an AdvOidc.Login cookie that is shared across all WEDA systems (Portal, SRP, App). This cookie contains the authenticated user's UserId and TenantId.
| Property | Value |
|---|---|
| Name | AdvOidc.Login |
| Scope | Shared across Portal / SRP / App |
| Contains | UserId, TenantId |
| Expiry | 2 hours (default) |
Each system also maintains its own permission cookie (e.g. Portal.Permission, SRP.Permission) for local authorization decisions. The shared AdvOidc.Login is the identity layer; the system-specific cookies are the authorization layer.
Login
When a user hits a protected route in your app and no AdvOidc.Login cookie is present, redirect them to:
GET {domain}/{tenantPath}/portal/external-login?returnUrl={returnUrl}
| Parameter | Description |
|---|---|
domain | Base URL of the WEDA deployment, e.g. https://tpe.cloud.advantech.com |
tenantPath | Tenant path segment, e.g. central |
returnUrl | URL to redirect back to after successful login |
What Portal does:
- Authenticates the user with the Identity Server (OIDC)
- Issues the
AdvOidc.Logincookie - Redirects to
returnUrl
Your app then calls Create JWT access token (POST {domain}/{tenantPath}/{appPath}/api/v1/auth/tokens) — no body required, the request uses the AdvOidc.Login cookie set in the previous step. The response returns an accessToken and refreshToken. Use accessToken as the Bearer token for all subsequent WEDA API calls.
The tenantPath in the redirect URL must match the tenant the user belongs to. An incorrect tenant path will cause the login to fail or authenticate against the wrong tenant.
Logout
To log the user out, redirect to:
GET {domain}/{tenantPath}/portal/external-logout?returnUrl={returnUrl}
What Portal does:
- Calls Identity Server's logout endpoint
- Sends Back-Channel Logout notifications to all connected clients
- Clears
AdvOidc.LoginandPortal.Permissioncookies - Redirects to
returnUrl
Do not attempt to clear AdvOidc.Login directly from your app — always go through the Portal logout endpoint to ensure all sessions are properly terminated.
Tenant Switching
Tenant switching is handled entirely by Portal. Redirect the user to the Portal tenant-switch flow; your app does not need to implement this logic.
After switching, Portal issues a new AdvOidc.Login cookie with the updated TenantId and redirects back to your app.
Summary
| Action | Endpoint |
|---|---|
| Login | GET {domain}/{tenantPath}/portal/external-login?returnUrl=... |
| Logout | GET {domain}/{tenantPath}/portal/external-logout?returnUrl=... |
| Tenant Switch | Handled by Portal |
Related
- Authentication — obtaining bearer tokens for API calls (SSO 5-step flow + M2M)
- MUI Boilerplate Overview — the frontend template that implements this flow