device-session-management

Manage secure device session authentication, validation, and revocation for unattended totems.

Updated Feb 16, 2026
One-click install
npx skills add https://github.com/Fivents/one-id --skill device-session-management
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: device-session-management
Source: https://github.com/Fivents/one-id/tree/main/.claude/skills/device-session-management
Command: npx skills add https://github.com/Fivents/one-id --skill device-session-management

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Devices such as totems need a dedicated session model separate from user sessions to prevent privilege leakage, enable short-lived credentials, and allow reliable revocation and auditing for unattended check-in flows. Mixing device and user sessions increases security risk, complicates expiration and revocation, and makes anomaly detection harder.

Core Features & Use Cases

  • Isolated Authentication: Authenticate devices using a secure credential (accessCode) and issue a hashed session token.
  • Lifecycle & Validation: Store sessions with expiresAt, validate the session on every request, and enforce expiration checks.
  • Binding & Security: Bind sessions to totemId and optionally validate IP and userAgent; support revocation on suspicious activity.
  • Use Case: A totem logs in with an accessCode, receives a TotemSession token which is used for check-in operations until it expires or is revoked.

Quick Start

Create a secure device session for totem TOTEM_ID using an accessCode, emit a hashed token stored with an expiresAt value (for example 30 minutes), and validate the token, bound totemId, and requester IP on each check-in request.

Frequently Asked Questions about device-session-management

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage secure authentication for unattended check-in devices?

Device session management separates unattended device credentials from user accounts by issuing a hashed session token bound to a specific totemId, enforcing expiration and revocation to prevent privilege leakage. This isolation simplifies anomaly detection.

How do I enforce session expiration and validate tokens for event totems?

Session expiration and token validation are enforced by storing an expiresAt timestamp with the hashed token and checking both the token validity and expiration on every request, allowing reliable revocation for unattended check-in flows.

Can I bind a session token to a specific totem and validate the requester IP?

Yes, sessions can be bound to a specific totemId and optionally validated against the requester IP and userAgent on each check-in request, ensuring the token cannot be reused from unauthorized environments or devices.

Why use a separate session model for devices instead of reusing user sessions?

A separate device session model prevents privilege leakage from unattended totems to user accounts, enables short-lived credentials, and simplifies reliable revocation and auditing for unattended check-in flows, reducing overall security risk.

What happens if suspicious activity is detected during a device check-in session?

If suspicious activity is detected, the device session can be explicitly revoked, immediately invalidating the hashed token and preventing further check-in operations until the totem re-authenticates with its accessCode.