apache
FauxtonUI Enabling Single Use JWT Authentication
Expected Behavior
CouchDB should allow for authentication via a JWT generated from an outside service. This would allow admins (and non-admins) to log into the UI using temporary tokens rather than static credentials. A general pattern for multiple authentication methods should also be established, keeping with Fauxton's general user experience guidelines. This is related but distinct to #1457, which mentions implementing a full Identity Provider Flow. These two methods can work together and are largely similar to each other under the hood.
When logging in, a user should be able to supply a token instead of a BasicAuth pair. When logged in, they should have access in the same way that a user with the same roles would.
When a token expires, the token should be deleted from the browser data, and the user will be automatically redirected to the login page. This is behavior similar to a session timeout today.
Current Behavior
Only BasicAuth is supported in the UI.
Possible Solution
Implementing a JWT login form as an option in a drop down in #login page. PR will be supplied.
Steps to Reproduce (for bugs)
- Attempt to log in with a token
Context
Users often want to validate their data in the UI. This can lead to sharing credentials to access the UI. These credentials may or may not be stored or handled properly. In scenarios where an environment is properly managed and secure, the credentials are not available to anybody and validating data becomes more difficult.
Allowing JWT in the UI would allow a user to get a short lived token from a token provider, log into FauxtonUI, and take a look at their data.
Your Environment
- Version used: 3.4.1
- Browser Name and version: Chrome
- Operating System and version (desktop or mobile): MacOS
- Link to your project: https://github.com/pablodavidortega/couchdb-fauxton
Hey @Stwissel, I agree that full auth dance with IdP is a good thing to add. I also think that that could be a separate but related change, as what you were proposing in your PR some time back.
The reason I say separate but related, is because in my opinion, that would also need to be supported on the CouchDB server side.
That said, the use-case that this specifically would allow is one where admins of the db can create short lived tokens in order to log into the cluster, rather than repeatedly using the same Basic Authentication.
Had that discussion on Slack and the key maintainers have signaled willingness to support this. Current idea is to add /_idp as an endpoint indicating available IdPs
That's fantastic news!
It might be a good idea to talk about making a framework so that common authentication methods are all supported. Taking Hashicorp Vault's available authentication methods as a good example, it's not a bad idea to enable end users with as many of these as possible in order to avoid BasicAuth being the de-facto standard.