Embedding the Izix Web App with SSO

Your app opens the Izix web app in a webview. The user signs in through your identity provider (SAML 2.0 or OpenID Connect), so there is no Izix password to manage. Booking, gate opening, plates and every other end-user feature are rendered and maintained by Izix.

This pattern is usually combined with Profile Provisioning: your system creates the profiles and their rights, the webview gives users access to them.

One-time setup

The SSO connection is configured on the Izix organization of each customer. Any identity provider that supports SAML 2.0 or OpenID Connect can be used.

Each connection belongs to one organization and has its own ACS URL or redirect URI.

Matching users to profiles

At sign-in, Izix matches the email sent by your identity provider with the email of a profile in the organization. Create profiles through the API with the email your identity provider will send, so rights and plates are in place before the first sign-in.

Just-in-time creation is an option, disabled by default. When enabled on the organization, a user who signs in without an existing profile gets one created from the SSO attributes, with the organization's default access rights, until an administrator or your system assigns specific rights.

Runtime flow

sequenceDiagram
    autonumber
    actor U as User
    participant APP as Your app
    participant WV as Webview
    participant WEB as Izix web app
    participant IDP as Your identity provider
    participant GATE as Izix gate hardware
    U->>APP: Taps "Parking"
    APP->>WV: Open the Izix web app
    WV->>WEB: Load
    alt No active Izix session
        WEB-->>WV: Sign-in screen
        WV->>IDP: Redirect to your identity provider
        IDP-->>WV: Existing session reused, or login prompt
        IDP->>WEB: SAML assertion or OIDC token (email, names)
        WEB->>WEB: Match email to profile, open session
    end
    WEB-->>WV: Home screen with the user's parkings and reservations
    U->>WV: Books a spot or taps "Open gate"
    WV->>WEB: Request
    WEB->>GATE: Open command (rights and position checked)
    GATE-->>WEB: Result
    WEB-->>WV: Confirmation

When a plate is registered on the profile, the user does not need the app at the gate: the ANPR camera reads the plate and Izix opens the barrier if the profile holds a valid right or reservation.

Webview recommendations

Container. Two options, with a trade-off on cookies:

• In-app browser tab (SFSafariViewController on iOS, Custom Tabs on Android) shares cookies with the system browser. If your identity provider session lives there, sign-in is silent.
• Embedded webview (WKWebView, Android WebView) gives full control over the chrome but keeps its own cookie store. Persist that store so users stay signed in between launches, and expect a login prompt from your identity provider the first time.

Do not use an iframe. Browsers restrict third-party cookies inside iframes, which breaks the session. Native webviews are not affected.

Location. Remote opening can be restricted to users physically near the gate (geofencing). It is configured per gate specification with a maximum distance. When active, the web app asks for the device position: grant the webview geolocation permission and forward the system prompt to the user.

Offboarding

Deactivating a user in your identity provider only blocks sign-in. The profile, its access rights and its registered plates remain valid in Izix, so the plate can still open the barrier. Remove the profile or its rights through the API, see Remove.

Combining with the API

The webview and the API work on the same data. Reservations created by your system with POST /reservations appear in the web app, and reservations made in the web app are returned by GET /reservations. Izix does not push events, so use filters[updated_since] to pick up changes.

If a customer prefers an API-only setup with your own screens, see Native End-User Integration.