The token.txt file contains the users encrypted Movere user ID and can only be generated by a Movere user with a ‘Write’ claim. As a result, Partners and Microsoft users cannot generate token.txt files.
The token.txt file has a 90 day lifespan, after that the Movere file transfer api will reject any payloads sent to it using the stale token.txt file.
The token file itself comes from the Movere IdentityServer which manages all tokens.
The token file cannot be decrypted, and even if it could, it does not contain the users Movere password, it’s just their Movere user ID and an authorization from the Movere IdentityServer allowing any payload with the token file as a header to pass through the file transfer api. If the payload was invalid or encrypted with a different PGP public/private key pairing then it still wouldn’t go anywhere as Movere would be unable to decrypt the file with the corresponding private customer key.
The token file itself is added as a header to every file uploaded and essentially says, who you are and which company you belong to?
Currently Movere uses IdentityServer v.3 because Movere runs on the .NET Framework. Movere 3.0 will run on .NET Core at which time we will be moving to IdentityServer v.4.
We currently use OAuth v2.4 to manage access levels.
NOTE: The token file has one other function and that is to automate the rescan process. From the Movere Console a Movere user with a ‘Write’ claim and a valid token.txt file can download a list of uninventoried devices only. It won’t download all device objects (just those needing to be scanned) and the token file MUST be run from the Movere Console with the correct customer GUID. If these do not align then nothing will be downloaded.