Improve authentication mechanism about server HOT 9 OPEN

I searched a bit through the available libraries. There are 2 gin-specific oauth libraries one based on the basic oauth lib and another one from zalando. But both are not updated in the last few years.

Another option would be to just use the basic oauth2 lib, that would also give some more freedom in handling the authentication, e.g. if you plan to make authentication mechanics switchable via config options.

from server.

I think the first option go-oauth2/gin-server appears fine, it glues together Gin (which we are already using) and the basic oauth2 lib. Presumably the reason why it seems so inactive is that there's not a lot of code, but still the code that's there is convenient for us to use. Since it's from go-oauth2, I would trust it more than some random package.

from server.

I implemented oauth as an optional authentication mechanism in a branch of my fork.

I would enjoy any comments and ideas on how to improve it further. Currently the only thing I am missing (and want to implemented) is the ability to create longterm tokens.

I intentionally tried to apply a modular scheme to the authentication process, so that other authentication methods can easily be implemented if needed.

from server.

Are there any standards and/or golang libraries you prefere for this? As I want to look into the actual implementation of such auth a little bit.

from server.

Hm, I think this depends on the goals we want to achieve:

• If we want to aim for a web-based UI, then we need to setup a login page where login data is posted to and verified, respond with a session cookie and keep track of user sessions.
• If the CLI is in focus instead, OAuth access tokens would be interesting: the login page returns a token (with limited lifetime), which is stored by pbcli and added to the Authorization header for any request it makes.

Personally, I'd prefer sticking to the CLI because it is less work to maintain, but happy to receive input on this.

from server.

OAuth sounds fine for me. It is a widely adopted standard so it can be used for a GUI later too. Maybe an option for longterm (limitied access) tokens might be great too.

from server.

That's awesome! Would you mind creating a pull request for it? We can treat it as WIP, but it makes the review more convenient.

from server.

Sure created #29

from server.

Thanks, will have a look on Tuesday!

from server.