I'm trying to replace the deprecated FME Token Service in our data download tool with the FMEServer Rest API but I can't see in the token methods how to include the username/password to create the token. How can I do this? Thanks.

You probably want to check the article Token Management in FME Server 2019.

Hi @Peter Baldwin​ ,

While we recommend using a token for security reasons, you can use Basic Authentication with any endpoint in the REST API.

If you were to use Postman or the HTTPCaller transformer in FME then there is a section for Basic Auth where you can just enter your username/password but this type of authentication can also be set up using a Header:

1. combine your username and password with a colon e.g. admin:admin
2. encode this string as Base64 e.g. YWRtaW46YWRtaW4=
3. Set the Header using this string e.g.

Authorization: Basic YWRtaW46YWRtaW4=

I'll go and update that article to include this information!

I was just looking into the same myself and was expecting to find a REST endpoint that generates a token from a username/password (as per the ArcGIS Server REST API) that can then be used for subsequent requests. It seems like the recommended way is to manually generate a long-lived API token, which to me seems less secure as anyone that got hold of the token could use it to authenticate.

The API endpoints for creating a token seem to assume you are alread authenticated as don't have username/password parameters. The only other way seems to be to use Basic Authentication to log in and then use the create token endpoints, but basic authentication is very insecure as user/password are sent in plain text.

This all seems to be a fairly major flaw in the authentication via REST and doesn't fit at all well with what we are trying to do, which is automate things using scripts that use credentials from a key vault. If using HTTPS, then having a "createToken" end point that accepts username/password/expiry with POST only would not be any less secure than manually generating a storing and using a long-lived token. I would argue it would be more secure!