Access cookie
vidyomni_access carries the short-lived access token. It is HttpOnly, so application JavaScript cannot read it, and uses the Secure flag in production.
Browser and session information
Know what keeps your browser signed in.
VidyOmni uses cookies for authentication, session renewal and request protection. Temporary cookies also support configured Google sign-in and the authenticator verification step.
Institution-aware workflows Role-based access
THE CONNECTED INSTITUTION
Clear responsibilities. Informed decisions.- 01Use a trusted browser
Keep your browser current and allow the cookies required to complete sign-in and protected application actions.
- 02Sign out on a shared device
Use the application’s sign-out action when finished, then close the browser on a computer others can access.
- 03Review other sessions
From a trusted signed-in account, review active sessions and revoke any device that should no longer have access.
- 04Clear browser data when needed
Use browser settings to remove site cookies. If a device is missing or untrusted, also revoke its session through the account workspace.
A practical journey to explore
A CLOSER LOOK
Each sign-in cookie has a specific job.
The browser receives an access cookie for authenticated requests, a refresh cookie for renewing the session and a CSRF cookie that the application reads when sending protected changes. Authentication tokens are not stored in browser localStorage by this implementation.
Refresh cookie
vidyomni_refresh supports session renewal. It is HttpOnly, uses SameSite=Strict and is scoped to the refresh endpoint.
CSRF cookie
vidyomni_csrf helps validate protected browser requests. Application JavaScript reads it to set a request header; it is deliberately not HttpOnly.
Temporary sign-in cookies
vidyomni_google_oidc and vidyomni_mfa_challenge support their respective sign-in steps when used. They are limited to the relevant callback or verification path.
HOW IT WORKS
Manage a session on your terms.
Shared and lost devices need different actions. Use account controls when a server-side session must end.
- 01
Use a trusted browser
Keep your browser current and allow the cookies required to complete sign-in and protected application actions.
- 02
Sign out on a shared device
Use the application’s sign-out action when finished, then close the browser on a computer others can access.
- 03
Review other sessions
From a trusted signed-in account, review active sessions and revoke any device that should no longer have access.
- 04
Clear browser data when needed
Use browser settings to remove site cookies. If a device is missing or untrusted, also revoke its session through the account workspace.
Scope and lifetime
Short-lived access, controlled renewal.
Cookie expiry and active-session validity are related but separate. A revoked session can stop working before its browser cookie expires.
Access lifetime
The access cookie follows the configured access-token lifetime. The repository default is 15 minutes; a deployment can configure a different permitted lifetime.
Refresh and CSRF lifetime
Their cookie maximum age follows the configured refresh-token lifetime, with a repository default of 30 days. Rotation, sign-out, password changes and revocation can end access earlier.
Temporary transaction lifetime
The Google sign-in transaction expires after ten minutes. The social MFA challenge follows its five-minute challenge lifetime. Each cookie is cleared by its callback or verification step.
Site and provider differences
No marketing analytics or advertising tracker is configured in the reviewed public-page source. A deployment, institution site or external provider may have additional behavior that its applicable notice should explain.
COMMON QUESTIONS
A few details
worth getting right.
Questions about your institution’s exact setup? Prepare a focused request.
Find the right contact routeCan I reject all cookies and still sign in?
Blocking the authentication cookies prevents the normal sign-in and renewal flow. Blocking or removing the CSRF cookie can also prevent protected changes. Public information pages can be read without signing in.
Does clearing cookies revoke a lost device?
Clearing cookies removes browser-held values on that browser. To end an account session on another device, use the active-session controls or ask your institution administrator for help with compromised access.
Why can JavaScript read the CSRF cookie?
The application must copy that value into a request header for protected actions. The access and refresh cookies are HttpOnly; the CSRF cookie has a different purpose and does not itself establish an authenticated session.
BUILD A CLEARER OPERATING DAY