HTTP Authentication

In enterprise networks, a Forward proxy often sits between users and the internet. Before allowing outbound traffic, the proxy checks whether the user is authenticated. If not, the browser is redirected through an Auth Service and a SAML Identity Provider (IdP) to verify credentials, then receives a token or cookie for later requests.

Authentication Flow

%%{init: {'themeVariables': {'fontSize': '16px'}, 'sequence': {'actorMargin': 70, 'messageMargin': 55, 'boxMargin': 30, 'useMaxWidth': true}}}%%
sequenceDiagram
    autonumber

    actor User

    participant Browser
    participant PAC
    participant FP as Netskope Forward Proxy
eproxy-acme-corp.goskope.com:8081
    participant Auth
    participant IdP
    participant Policy as Policy Engine
    participant Google

    User->>Browser: Open browser
    Browser->>PAC: Download PAC file
    PAC-->>Browser: FindProxyForURL() 
Send every HTTP to eproxy-acme-corp.goskope.com:8081

    User->>Browser: Open https://google.com

    Browser->>FP: CONNECT google.com
eproxy-acme-corp.goskope.com:8081

    FP->>FP: Resolve tenant_id from proxy FQDN
FQDN=eproxy-acme-corp is sent in HTTP Host Header
FQDN→tenant_id 1001 resolved
eproxy-acme-corp.goskope.com→1001
eproxy-contoso.goskope.com→2005
eproxy-xyz.goskope.com→3050
    FP->>FP: Check session cookie. MISSING
    FP-->>Browser: 302 Redirect to Auth Service

    Browser->>Auth: GET /login
    Auth-->>Browser: Redirect to IdP

    Browser->>IdP: GET Login Page
    IdP-->>Browser: Login Form

    User->>Browser: Enter credentials
    Browser->>IdP: POST Credentials

    IdP->>IdP: Authenticate User

    IdP-->>Browser: SAML Response

    Browser->>Auth: POST SAML Assertion

    Auth->>Auth: Validate Assertion
    Auth->>FP: Create Session

    FP->>FP: Cache Session
    FP->>FP: Generate Session Cookie
Session cookie is called UTKN(universal token)
nspatoken is name given by Netskope

    FP-->>Browser: Set Session-Cookie=XXX
    FP-->>Browser: Redirect google.com

    Browser->>FP: CONNECT google.com
Session Cookie=XXX 
    FP->>FP: Resolve tenant_id from proxy FQDN
FQDN=eproxy-acme-corp is sent in HTTP Host Header
FQDN→tenant_id 1001 resolved
eproxy-acme-corp.goskope.com→1001
eproxy-contoso.goskope.com→2005
eproxy-xyz.goskope.com→3050
    
    FP->>FP: User from cookie → bob@acme.com
groups from SAML session
    
    FP->>Policy: Evaluate Policy
tenant=1001,domain=google.com
method=CONNECT

    Policy-->>FP: ALLOW

    FP->>Google: Establish upstream TLS Connection
    Google-->>FP: TLS + HTTPS Response
    FP-->>Browser: Forward Response
    Browser-->>User: Google search page

    User->>Browser: Open github.com

    Browser->>FP: CONNECT github.com:443
SessionCookie=XXX
    FP->>FP: tenant_id 1001 (FQDN) + bob@acme.com (cookie)
    FP->>Policy: Evaluate Policy

    Policy-->>FP: ALLOW/BLOCK

    FP-->>Browser: Response

When does the session cookie expire?

The proxy session cookie (nspatoken / UTKN) can stop working for three different reasons. It forces the user back through authentication.
1. User closes the browser (all windows/tabs for that profile). Next browse session has no cookie → proxy redirects to login.
2. Admin policy — e.g. idle 8 hours, max 24 hours. Cookie may still be sent by the browser, but proxy lookup fails → treat as expired → 302 to Auth Service.
3. IdP may require password/MFA again after its own SSO timeout (often hours).
Cookie is regains after re-authenication.

Can the refresh token idea be used for session cookie? No

The refresh token concept (short-lived access JWT + long-lived refresh UUID stored server-side) solves a REST API problem. ie Renew credentials without asking for the password every 15 minutes.
Because browsers usually have one opaque session cookie (nspatoken)

Terms

Term	Meaning
Proxy	Intercepts HTTP/HTTPS traffic. Checks whether the user has a valid session or JWT before forwarding the request to the internet.
Auth Service	Handles login, generates a State ID (CSRF protection), validates the SAML response, creates a JWT, and sets a cookie on the browser.
SAML IdP	Identity Provider — validates username/password (or MFA) and returns a signed SAML assertion proving the user’s identity and group membership.
State ID	Random value tied to the login attempt. Prevents replay and CSRF attacks by ensuring the SAML response matches the original login request.
JWT	JSON Web Token created by the Auth Service after successful login. Contains user identity and groups. The proxy sends this to the Auth Service on each request for validation.
Session cookie (nspatoken / UTKN)	Opaque cookie set by the forward proxy after login. Browser sends it on every CONNECT. Maps to server-side session (user, groups, tenant). Expires per browser session, proxy TTL, or IdP SSO. Regained via re-authentication flow — not via REST refresh token API in typical SWG.