Is generating bearer token the only way to access API? #400
-
|
Hello. Is generating a token using basic auth and then using that token for limited time before renewing the only way to use the API? Is there maybe a way to disable API authentication or use predefined credentials for it? I use API through unix socket, so going through all these hoops is kinda excessive. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 15 replies
-
|
Hi, yes this is the only way. This is not only for security reasons but also for performance, using jwt we can read the user and the permissions from the token, if we use basic auth, as before 2.0, we have to do a data provider query to get permissions for each request. We now have authentication and authorization, before 2.0 we had only authentication, we cannot easily revert back to the old model, sorry |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I could consider and accept a such contribution after v2.1 if this doesn't increase too much the maintenance burden. Can you please share more details about your proposed solution? Do you mean something like this? So basically we should allow to add an access token for each admin and validate it for each request. If we want to mantain the short lived JWT token too we should add a different auth header. A full oauth flow like this one seems excessive to me. Given that if you don't use https no authentication method is secure, a short lived token is intrinsically more secure than a permanent one. The main avantage of using access token instead of passwords is that they are not vulnerable to brute force attacks, the same can be achieved using a strong password. Maybe another alternative could be to allow client certificate authentication (the certificate common name must match the username for example as we already did for FTP and WebDAV). Regarding the current solution you could store the token and its expiration and make a new request only if the token is expired or is about to expire, this way SFTPGo does not have to hit the database to validate permissions for each request and you have an additional round-trip only if the token is expired, please take a look at the example here. A permanent token will likely require a per-request database query instead. Anyway I'm open to discuss any solution that can improve the things, thank you |
Beta Was this translation helpful? Give feedback.
-
|
I prefer the first one myself (the jetbrains.com link). I think the OAuth flow you linked is indeed excessive and would definitely complicate the application. But even the simpler one would add a maintenance burden. I'll think about this, but I doubt I'll have the time to build a prototype anytime soon. I'd prefer a much simpler approach for automated access, but in my mind the jetbrains approach would be the only option for APIs. Having two ways to hit APIs is probably too confusing. |
Beta Was this translation helpful? Give feedback.
-
|
I disagree, API keys are intrinsically less secure than short-lived access tokens. I might add API keys or something similar in the future, but this will likely be in addition to the existing authentication. Anyway some users (companies) are performing security audits against SFTPGo, we will see what changes they suggest, if any, regarding authentication. Performance wise, as explained above, if you use the JWT tokens the wrong/lazy way (requesting a new token each time) you will have similar performance to the approach you suggest since api keys will likely require a database lookup for each request. Over the past few days I have also checked how other similar (proprietary) software authenticates their APIs, some use the same authentication as SFTPGo, others prefer API keys, and others allow both. So the method we currently use is not so uncommon. |
Beta Was this translation helpful? Give feedback.
-
|
I think the vault can be considered an authoritative source on this topic, please take a look here: https://www.vaultproject.io/docs/auth |
Beta Was this translation helpful? Give feedback.
-
|
API key authentication is now supported |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, they have a good setup for sure. The sort of flow I was thinking of would be something like https://learn.hashicorp.com/tutorials/vault/approle. I like that it spells out which parts are human (e.g., provisioning the approle auth and generating a role + policy) vs. those which would be fully automated. I also like that they don’t tie an approle to a user account, so you can just generate a very granular API endpoint that can only do a fixed number of operations. And of course, my favorite, being able to generate tokens with a custom expiry time (including never-expire tokens) 😊
But all that flexibility will come with a cost. I mean, Vault’s entire purpose is secret management, so of course it’s very robust and highly configurable. It could be an immense undertaking to try and get even half the functionality they’ve built. I wouldn’t be disappointed to see something like this, but I imagine it would be a huge time sink.
If I get time I’ll look into it, but I don’t know if/when I could contribute anything massive like that ☹
From: Nicola Murino ***@***.***>
Sent: Tuesday, May 25, 2021 12:58
To: drakkan/sftpgo ***@***.***>
Cc: Jeremy Echols ***@***.***>; Comment ***@***.***>
Subject: Re: [drakkan/sftpgo] Is generating bearer token the only way to access API? (#400)
I think the vault can be considered an authoritative source on this topic, please take a look here:
https://www.vaultproject.io/docs/auth<https://urldefense.com/v3/__https:/www.vaultproject.io/docs/auth__;!!C5qS4YX3!WyCnHyUlVA0asMpLEArwf8BCzC6WDPokiohShzzCv3LC_YISFWjgFY5bdicb7OK8QA$>
https://www.vaultproject.io/docs/auth/approle<https://urldefense.com/v3/__https:/www.vaultproject.io/docs/auth/approle__;!!C5qS4YX3!WyCnHyUlVA0asMpLEArwf8BCzC6WDPokiohShzzCv3LC_YISFWjgFY5bdidcdQ1Png$>
https://www.vaultproject.io/docs/auth/app-id<https://urldefense.com/v3/__https:/www.vaultproject.io/docs/auth/app-id__;!!C5qS4YX3!WyCnHyUlVA0asMpLEArwf8BCzC6WDPokiohShzzCv3LC_YISFWjgFY5bdif1fLzNxw$>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/drakkan/sftpgo/discussions/400*discussioncomment-783046__;Iw!!C5qS4YX3!WyCnHyUlVA0asMpLEArwf8BCzC6WDPokiohShzzCv3LC_YISFWjgFY5bdif5twLQmw$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AAQO3FU2W5KJWMDIFQ5IU6TTPP6K3ANCNFSM4333P62A__;!!C5qS4YX3!WyCnHyUlVA0asMpLEArwf8BCzC6WDPokiohShzzCv3LC_YISFWjgFY5bdidTqqiBSA$>.
|
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure that vault allows infinity lifetime for non root tokens, anyway this is not important. I would be happy to review your PR if/when you find some time to work on this. Short lived tokens must remain. Something similar would also be useful for impersonating users. I recently added a web UI which for now only allows you to browse files. I haven't exposed the API for this yet, as I was thinking about how an admin user could impersonate SFTP/FTP/WebDAV users without knowing their credentials. Impersonating a user is useful, for example, within hooks to perform file operations on cloud backends. So if I ever add this feature, I could implement your request as well. Either way, as you've noticed, this is a huge task and will likely happen if someone sponsors it |
Beta Was this translation helpful? Give feedback.
-
|
The impersonation I previously spoke to Nicola about was intended to be at the file access level with windows users having the same name as the corresponding SFTPGo user (Using say advapi32.dll at the OS level). https://gist.github.com/kostix/68022534e22cc239a917 I understand that this is quite a large job. Windows impersonation for me we be good for the reason that Windows ACL can provide another layer of permissions checking (And also systems such as Filesure [Bystorm] which provide another layer of ACL and logging).
I agree this would be useful. One immediate option seems to be a custom authenticator which SFTPTGo already supports. For me windows impersonation at the OS level, is more important, but due to personal circumstances, I am not in a position to support it yet. I would like to be back to work and using SFTPGo first. |
Beta Was this translation helpful? Give feedback.
-
|
I hope to write an authenticator for keycloak/traefik OIDC. When finished, I will share it. Go plugins if related to the above, seem not to be available for windows. The API already looks great. |
Beta Was this translation helpful? Give feedback.
-
|
@drakkan Do you mean a plugin for a vfs in relation to Windows impersonation? |
Beta Was this translation helpful? Give feedback.
-
|
At some point I could add "official" plugins/hooks for the most common use cases, for example notifications to pub/sub systems, ldap auth etc. Your authenticator could live there, thank you |
Beta Was this translation helpful? Give feedback.
-
The plugin system will be based on this, so it will work on Windows too. I have a proof of concept already working locally. I have to finalize some things before pushing it to the public repo. Initially only events notifications will be exposed as plugins: for example notifications after a file upload, rename, etc. The next things will be the kms, I want to leave only vault within the core SFTPGo and move GCP, AWS, Azure to an official plugin. A vfs is quite complicated but I hope to be able to expose it as a plugin too. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @drakkan - excellent too that the plugins will work on windows. |
Beta Was this translation helpful? Give feedback.
Hi,
yes this is the only way.
This is not only for security reasons but also for performance, using jwt we can read the user and the permissions from the token, if we use basic auth, as before 2.0, we have to do a data provider query to get permissions for each request. We now have authentication and authorization, before 2.0 we had only authentication, we cannot easily revert back to the old model, sorry