Skip to end of metadata
Go to start of metadata

Why use tokens instead of signatures?

Consider a site that contains more than just a single page (and signature-based authentication). A user authenticates (user/pass) on one page, and their credentials must be used to sign all their requests. All pages a user opens must have access to the password so they can sign all requests to apstrata. The password must somehow be made accessible to all pages and/or be available to the webapp (in plain text) to sign requests to apstrata. Tokens provide a viable alternative. A user requests a token and can only use it over a secure (https/post) channel. The token can be used instead of the signature for most functionality. The token can be stored in a cookie and the user's web browser will automatically forward the token with every request made - the webapp will not need to keep track of the user's password, and no client-side Javascript or cookie is required to make the token accessible by all pages of the site.

When the entity invoking Apstrata is a device, resorting to a token to authenticate the latter against the APIs is an interesting option, as it simplifies the authentication process while maintaining a good level of security. When using tokens, devices do not need to store an id and a password, nor to generate a signature, which can be pretty convenient if the device has limited capacity. In addition, it is always possible to regenerate a token on demand, after having discarded the existing one in case you think it has been compromised.

A simple way for a Javascript-enabled application to use tokens is through the Apstrata Javascript library ApstrataSDK which handles tokens with the TokenConnection class. Using TokenConnection connections ensures the proper use of tokens since it only takes credentials once and does not store the password anywhere while still allowing the token-based session to be shared across multiple pages. The class also handles the token renewal mechanism which, by default, requires the token to be renewed every 30 minutes and invalidated every 2 hours. Successful and failed logins, logouts, and API calls are all clearly documented in code and published by this class using the Dojo publish method; this allows applications to subscribe to any event handled by the connection in case it needs to set customized functionality. An example of this is when a token is invalidated and the application needs the user to login again, then a "logout" event is published and an application can subscribe to that channel and show the login screen.

  • No labels