What is an Alien Session? Authentication State Explained

An Alien Session is a unique, cryptographically-verified session a user creates once for your application (provider). It is the authentication state your app checks every time that user signs in.

How Alien Sessions Work

When a user authenticates with your mini app, web app, or application through Alien SSO for the first time, a session is created once for that specific provider. Each session is created inside Alien’s secure-execution infrastructure (Frame, MPC-based TEEs) — you don’t need to understand this layer to integrate.

This session is a permanent, verified connection between the user (their Alien ID) and your application (the provider). The same session is reused for every subsequent sign-in by that user with your application.

For the deeper reasoning behind sessions, read Alien founder Kirill Avery’s article: Proving You’re Human: How to Solve Privacy in the Era of AI .

Stored on Alien Network

Sessions are anchored on the Alien Network as verifiable records: Solana SSO records attestations immutably on-chain, while standard SSO validates against the user’s on-chain identity but stores OAuth session and token state server-side, where it expires. This ensures:

• Transparency: anyone can verify a session’s authenticity on-chain.
• Tamper-proof: once created, sessions cannot be modified or forged.
• Decentralized: no central authority controls session data.
• Privacy: a user’s personal data never leaves their device.
• Permanent audit trail: full history of session creation and lifecycle.

Managed via Alien ID

Sessions are created and managed by users through their Alien ID:

• Users control which sessions to create and for which applications.
• Users can revoke sessions at any time through their Alien ID.
• All session actions require user authorization via their Alien ID.
• Private keys never leave the user’s device.

Unique Per User and Provider

With standard SSO, each session is unique and tied to both the user’s Alien ID and your specific provider:

• The same user gets a different session for your app than for any other app they sign in to.
• Each session is isolated and cannot be reused across different providers.
• Sessions are tamper-proof and verified on-chain through cryptographic proofs.

Note. Solana SSO works differently: wallet attestations bind the user’s wallet to a single platform provider, not to each individual dApp. See the Solana SSO Guide for details.

One Session = One Person

This architecture provides strong protection against bots and fake accounts.

Bot Protection

• Cryptographic verification: each session is created in an execution layer within Frame TEEs and signed with the session’s authentication key (not the user’s root identity key).
• One identity per person: the Alien Network ensures each person has only one Alien ID.
• Session uniqueness: bots cannot duplicate or forge sessions without access to the user’s private keys.

Sybil Attack Prevention

• On-chain verification: sessions are validated against on-chain records (Solana SSO attestations are themselves stored on-chain).
• Provider isolation (standard SSO): sessions cannot be shared or transferred between different applications.
• Proof of personhood: each session is backed by an Alien ID.

Session Lifecycle: Creation, Refresh, Expiry

1. Creation

When a user approves authentication in the Alien App:

• A session is created in an execution layer within Frame TEEs.
• A session address is generated.
• The session is recorded on-chain (for Solana SSO) or verified on-chain at callback, after which a signed JWT is issued as the bearer credential (for standard SSO).

The session address is the sub claim in the tokens your app receives — your stable, per-provider user identifier. Store it as the user’s ID.

2. Active

While the session is valid:

• Your app can verify the user.
• The user’s approved claims (name, avatar) are available.
• The session cannot be tampered with or forged.

3. Revocation

Sessions remain active on-chain until revoked:

• Users can revoke sessions at any time through their Alien ID.
• Only the session creator (user) can revoke their sessions.
• Once revoked, a session cannot be restored.

Token lifetimes. The on-chain session persists until revoked, but the tokens issued by standard SSO expire on their own schedule: access tokens are short-lived (the server enforces a 15-minute maximum), ID tokens default to about 1 hour, and refresh tokens to about 30 days. Reusing an already-rotated refresh token revokes the whole token family.

Benefits for Your Application

Security

• No password management: users don’t need passwords for your app.
• Non-custodial: you never have access to users’ private keys.
• Cryptographic proof: each session is cryptographically verifiable.

User Experience

• One identity everywhere: users keep one global Alien ID, but create a separate session per app — there is no shared cross-app login session.
• Privacy control: users choose which claims to share with your app.
• Mobile-friendly: QR code or deep link authentication.

Compliance

• GDPR-friendly: users control their own data.
• Audit trail: all sessions are verifiable on-chain.
• Data minimization: only approved claims are shared.

Session vs User Identity

It’s important to understand the distinction:

A single user has one Alien ID but can have multiple sessions across different applications.

Next Steps

• What is an Alien Provider? — register your app on the Alien Network
• SSO Guide — integrate standard SSO
• Solana SSO Guide — link wallets on-chain