Sessions and sign-out

A successful sign-in proves that the user held the device's keys at that moment. What happens next is up to your application. You create the session, you decide how long it lasts, and you end it. Triauth gives you two ways to confirm during the session that the user is still who they were.

Check: verify the device is still listed in DNS

Triauth.check reads the user's records again and tells you whether the device that signed in is still published, unchanged.

It runs on your server, needs no interaction, and costs a DNS lookup. Call it at the request boundaries that matter, for example before a sensitive action, or on a timer. It also returns the identity's current groups. Replace any groups you cached at sign-in with them.

If the user signed in through a delegation, the check also confirms that the grant still exists.

API reference:JavaScript

Ping: ask for a fresh signature

Triauth.ping asks the user's device to sign a new request. It follows the same three stages as sign-in, and the authenticator usually answers without showing anything when the device allows it. It proves that the session is still in the hands of the user's device. A session cookie copied to another device cannot answer a ping, so a hijacked session stops working at the next one. A DNS check cannot tell you that.

A ping is a redirect through the browser. Use it at session boundaries and before step-up actions, and not on every request.

API reference:JavaScript

How often

Triauth.authenticate, Triauth.check, and Triauth.ping results carry an expires hint derived from the time to live of the DNS records. Treat it as a hint. Set your own minimum interval as you would with any operation that makes network requests.

Sign-out

Sign-out is yours. End the session on your side. The authenticator keeps no session for your website, only the permissions and tokens that the user granted, which the user can revoke by forgetting your website.