0036095: Cannot create API token programmatically - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0036095	mantisbt	api rest	public	2025-06-30 01:32	2025-07-20 03:52

Reporter	gthomas	Assigned To
Priority	normal	Severity	minor	Reproducibility	always
Status	new	Resolution	open
Product Version	2.27.1

Summary	0036095: Cannot create API token programmatically
Description	My use case is to transfer my CLI program from username:password to username:token. The REST api exposes /users/me/token to allow creating a new Token for token-based authentication, but the REST api REQUIRES token for authentication. So I cannot use it to create a token, as I only know a password. The SOAP api allows both password and token based authentication, BUT does not expose a CreateToken function.
Tags	No tags attached.

gthomas 2025-06-30 01:34 reporter ~0070365	Two solutions I see: a) make the REST api allow password-base authentication - this may go against some security paradigms b) add a CreateToken function to the SOAP api. Which would be accepted as a PR?

gthomas 2025-06-30 05:15 reporter ~0070366	https://github.com/mantisbt/mantisbt/pull/2141 is solution b).

dregad 2025-07-16 05:14 developer ~0070387	@vboctor, the user is raising a valid point here, user needs a token to create a token with the `POST /users/me/token` endpoint, a use case that is not covered by the implementation (0032245). This was already identified in 0033489:0068441. How do you suggest addressing this ?

vboctor 2025-07-20 00:57 manager ~0070396	I have been trying to avoid including username and password support in REST API and hoping that SOAP API becomes disabled by default and eventually removed. The reasons for avoiding passwords are: MantisBT supports different modes of authentication via plugins. Hence, username + password wouldn't always work. username + password is not secure due to brute force attacks, password re-use, and inability to limit what an app can do via tokens (not currently implemented, but can be). What I don't understand is why the CLI can't be configured to use a token instead of a password. Similar to `.aws/credentials` and similar approach. In such case you can use the token if a specific user to access MantisBT as such user or use an admin token and even be able to impersonate any user you want. The scenario of using a token to create another token is mainly used for provisioning scenarios. Where an app can use an admin token and be able to create and dispense tokens for other users. It is also unclear to me if you use an API to create a token that is persisted, how often are you going to create such token? If we are ever to consider this scenario, I think we would be using non-persisted and expiring JWT tokens. But it would still not address the top concerns. I can understand that you may persist the created token on the client in a file, but if so, why not persist the token instead?

gthomas 2025-07-20 03:52 reporter ~0070398	I don't want username+password support in REST API, I want to use tokens. This functionality (create API token from SOAP) is needed to ease the transition from username+password auth to token-based auth: when the user is authenticated with username+password, then my CLI creates a token and replaces the auth in the config file accordingly. As this is just a one-time need (till my users move to token based auth), I can live with it (enable it in my instance for a while).