you could store it as a non-persistent like Tim said, and then associate it to the session table in the system module. Then in other microflows you can use retrieve by association from the current session to retrieve the token. Then validate with an exclusive split that the token is not empty. if it is empty then call the rest service again.
If you do go with this approach then just beware that it could lead to a performance hit. I would read the "exceptional cases" section in this doc.
It will return a list every time. You could use a the list operation head to retrieve the top object (in this case it will be the only object)
I would advice to create an entity for your specific call, in my example "RestToken" in which you store the token value. You associate it to the "Account" entity, 1 on 1.
Afther that you can make a simple microflow which retrieves the restoken if available and else creates it and associates it to the current account. I've created a modelshare so you can simple see what i mean. Further, I expect your token isn't valid indefinitely, so you could create an attribute with the value till which your token is valid and you can check if it's no longer valid, if not you can call a microflow to retrieve the new token and change the RestToken object attribute to the new expiration date.