Table of Contents
Login Tokens (Legacy)
15. April 2026
Table of Contents
Legacy notice
This is a legacy integration feature. Do not use it for building new integrations.
- Do you want your users to log in via an external service? Consider using SSO
- Are you building an interactive app, such as a web, mobile, or desktop app? Consider using OAuth
- Are you currently using the ArchiveAgent API? Consider using the new Fotoware API
- Are you using legacy widgets? Consider using the new approach for embedding widgets using OAuth
The following content is legacy
Login tokens can be used to log in a user and create a user session from within a third-party application that handles authentication.
Note that this is not a method for authenticating API clients.
Usage
Login tokens are useful when creating a third-party application that integrates with the FotoWeb user interface. Normally, users have to log in to FotoWeb using the FotoWeb login form to be authenticated and access FotoWeb resources. With login tokens, a user only needs to log in once, using an authentication mechanism provided by a third-party application.
The third-party application creates the login token and passes it to FotoWeb via a URL. FotoWeb validates the login token and, if it is valid, redirects the user to the specified resource within FotoWeb.
Login tokens have a limited lifetime, set by the third-party application that generates them.
Note: Login tokens will not work for the site owner
Login tokens do not work for the user who is the site owner. This is for security reasons, to prevent impersonation of the site owner by a user who is not the site owner but does have permissions to manage users and security. Allowing impersonation of the site owner would be a security risk, as that user has special privileges.
Authentication, as this does not account for clock differences when the host's clock that creates the token is behind the FotoWeb server's clock
Before a third-party application generates a login token, it has to authenticate the user. This is entirely the responsibility of the third-party application and outside the scope of FotoWeb. For example, the third-party application may use its own username/password authentication and a mapping from its own users to FotoWeb users. It is also possible to use single sign-on, LDAP (set to End of Life on January 1st, 2024), Active Directory authentication, or other methods.
Tip: FotoWeb can be integrated with your Active Directory. Learn how to do so and how to import the groups that should be allowed access to the system.
We do not recommend storing FotoWeb user passwords in third-party applications, and there is no way to extract user passwords from FotoWeb. A third-party application using login tokens does not need to know FotoWeb user passwords.
Generating Login Tokens
Once the user has been authenticated, a third-party application can generate a token for logging the user in to FotoWeb. To generate the token, the application must implement the token generation algorithm and know the encryption secret of the FotoWeb site.
Every token consists of the following:
- start and end date and time between which the token is valid
- user name
- signature
The signature is a hash value of the other values. It is used to prevent malicious applications from forging login tokens.
Sample code for generating tokens is publicly available:
Applying Login Tokens, as this does not account for clock differences when the host's clock that creates the token is behind the FotoWeb server's clock
To log in a user with a valid login token, redirect or link the user to the following URL in the browser:
http://hostname/fotoweb/services/tokenlogin?lt=token&to=url
where hostname is the hostname of the FotoWeb site, token is the login token generated by the third-party application, and url is the URL to redirect the user to after successful login.
The to parameter is optional. If it is not given, the user is redirected to the start page of either the FotoWeb Pro interface or the main interface after successful login. This depends on whether or not the user has a Pro user license.
If the login token is valid, the user will be redirected to the given URL. Otherwise, an error page will be shown to the user. This should not normally happen since the third-party application should always create valid login tokens.
Token validity
Every token has a defined start and end time during which it is valid. Start and end times are given as UTC. When developing an integration that uses login tokens, you can decide the token validity.
A token is accepted by the server if and only if the UTC time on the server is within the validity range at the time of receiving the token.
Even if the client and server clocks are in sync (as they often are in a domain with SNTP time synchronization), latency can introduce additional differences between when the token is created and when it is received. Clock differences in both directions can cause the token to be received after or even before it is valid.
To avoid such problems related to token validity, we recommend the following:
- Ensure that the host that creates the tokens and the FotoWeb server have synchronized clocks, ideally set to the correct time. The clocks don't need to be highly accurately synced. A few seconds in either direction should not cause any issues.
- When creating a token, define its validity range so that it begins slightly before the time the token is created and ends slightly after the time it is expected to be received, accounting for the expected latency.
Note
You SHOULD NOT set the start time (S) to the creation time (C) because this does not allow for clock differences where the host's clock that creates the token is behind the clock of the FotoWeb server. However, if the clocks are in sync, latency usually mitigates this problem, so the minimum latency becomes the maximum acceptable time difference.