Any ideas on how best to store API tokens for different users, ideally preventing other users (or system administrator) to gain access to another person's token and impersonate them? I guess I could require a password for each user to decrypt once per session, but that would also prevent the code from running in a "headless" mode. Is there a best approach for this or is there no way to get both secrecy and code that runs without prompting the user for a green light?
Storing data for each user in a system is easy. Provide a table which allows users to create records. Allow them to read records which they create but not to read records created by anyone else.
You have to clarify what you mean by "(or system administrator)". In my mind, the sysadmin is the person who controls the system, in a FileMaker context they will have Full Access privileges. That means that they have full control of the data. You can store the data somewhere else but that just defers the problem. That "somewhere else" will also have someone who has full access to the data.
1 Like
Be very careful to never store tokens or related in an unencrypted format.
One approach would be to instead (of storing plain-text tokens) is to store the token in a 512 Hash. Then, when the user sends in their token, you hash it and compare it with the stored hash (no "decryption" needed). This technique makes sure you don't leave exposed plain-text authentication information around that could easily be hacked.
Another approach would be to use RSA.
I've used both techniques, but never EVER store any password, token, or similar in plain text on a server!
HTH
1 Like
I'm sorry for not clarifying that I'm not the API provider.
I'm simply putting my solution in front of someone else's API.
I do understand that an API provider would have to hash the tokens or anything used to authenticate the user.
On my end, If I could afford the user sending a token each and every time, I would not store anything and let the API connection fail if the token provided is faulty. Because of this, my design may result in asking the user to encrypt the token with a password of his choice. The password would not be stored or hashed. If the user forgets the password, they will have to create a new token. I would like if I could skip asking the password once per session, but I guess that would lead me somewhere tokens would be too easily accessible.
@anon45965781 does that clarify? Would that change what you wrote earlier?
Sorry, I wasn't meaning to give you a hard time above if it came across that way. 
It's difficult to know for sure how secure your proposed solution is without knowing a bit more about your design. The problem with passwords, their vulnerability, (the problem PKI solves) is that the password must be transmitted (and possibly intercepted).
Perhaps an UML activity diagram or something would clarify further.
HTH
For my specific setup, everything will be in FileMaker Pro.
In order not to have FileMaker act as a single user with the API, I will need to ask each user to create a token with the API provider and make FileMaker aware of what that token is.
I want FileMaker to be able to retrieve that token for the user who owns it, but not for anyone else.
That's why I figured I could encrypt the token the user will give FileMaker with a password the user will choose. The password would not be stored or hashed.
To retrieve the token, FileMaker will ask the user for his password and if the user forgot his password, he can simply create a new token. That should leave little to no space for the password to be compromised.
For someone to get access to a token, they would need to decrypt it based on the encrypted value. If someone does get the encrypted data in their hands, I do understand they will be able to put all the computing power they want to attempt to decrypt it without prior knowledge of the user's password.
There is no way, in FileMaker, to prevent a [Full Access] user from accessing any data. You will need to encrypt the data in the field yourself if you intend to prevent this user from reading some data. Is there a reason to distrust the [Full Access] user when he has access to pretty much everything else?
As for other users… you could use FileMaker's own security model to ensure only the logged-in user has access to a given field and record.