Giter VIP home page Giter VIP logo

moapis / authenticator Goto Github PK

View Code? Open in Web Editor NEW
14.0 2.0 2.0 1.25 MB

A stand-alone gRPC based authentication API. Easily integrate authentication into any custom project. Authenticator takes care of user credential storage and checking. It generates JSON Web tokens for users, which easily can be verified by other servers in your ecosystem using performant and secure EdDSA public key cryptography.

License: BSD 3-Clause "New" or "Revised" License

Go 88.03% Dockerfile 0.82% HTML 7.14% JavaScript 3.74% Shell 0.27%
golang go sqlboiler argon2 jwt-server jwt password password-hash adminlte3 grpc grpc-server grpc-go eddsa

authenticator's Introduction

Build Status codecov GoDoc Go Report Card

Archived

My intentions to where to develop an opensource drop-in solution for authentication. As I was searching to evolve this project to implement more standards than just JWTs, (like OAuth2, OpenID connect etc), I came across this wonderfull product that did already did most off this and have a roadmap with everything I could possbily dream of this project ever becomming: https://github.com/zitadel/zitadel. As they are a company with a good team there was no way I was ever going to catch up with their development speed alone. Hence, I decided to join them :).

Therefore I don't see any merrit continuing this project anymore. Thanks for those few stars and if you need something better, be be sure to checkout ZITADEL and their open-source or commercial offerings!


Authenticator

A stand-alone gRPC based authentication API. Easily integrate authentication into any custom project. Authenticator takes care of user credential storage and checking. It generates JSON Web tokens for users, which easily can be verified by other servers in your ecosystem using performant and secure EdDSA public key cryptography.

Benefits:

  • Added security, the user credentials live in a seperate database schema as you application's one. Creating a strict seperation in database access;
  • No more password checking logic in you application. Just send a API call to authenticator and check the generated token on each subseqeuent request;

Fautures

  • gRPC based, simply implement a client in your own preferred language by compiling protobuffer files;
  • Support for master/slave database setups using our own MultiDB library;
  • Admin panel for user management;
  • A basic HTTP based login server, based on redirects;
  • Argon2 hashed password storage;
  • User groups and "audiences" for fine grained authorization checking;
  • Comes with the verify Go library, which has ready to use token verification methods to integration even easier;

Status

This project is still under heavy development. We've recently deployed a beta version of the gRPC and admin server.

Future plans

  • Two factor authentication
  • OAuth2 provider support

Development

When developing against Authenticator, there is a docker-compose.yml file which sets up a development infrastructure. It start a postgresql instance, runs the neccesary migrations and start the server instances. You can download the Compose file or run this from the root of the repository:

docker compose up
  • The authenticator gRPC server will be served at port 8765.
  • The admin interface will be served at port 1234.

The defaut user is "admin@localhost", password "admin", member of the group "primary" and audience "authenticator".

Protocol buffers

The authenticator server uses gRPC through protocol buffers generation. To regenerate the gRPC definitions, run:

protoc --go_out=plugins=grpc:$(go env GOPATH)/src authenticator.proto

authenticator's People

Contributors

muhlemmer avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

Forkers

bellyfat djun

authenticator's Issues

Server: refactor token verification to use the full verify library

func (rt *requestTx) checkJWT(token string, valid time.Time) (*jwt.Claims, error) {
log := rt.log.WithField("token", token)
if token == "" {
log.WithError(errors.New(errMissingToken)).Warn("checkJWT")
return nil, status.Error(codes.InvalidArgument, errMissingToken)
}
kid, err := verify.ParseJWTHeader(token)
if err != nil {
log.WithError(err).Warn("tokens.ParseJWTHeader()")
return nil, status.Error(codes.Unauthenticated, "Invalid token header")
}
key, err := rt.findJWTKey(kid)
if err != nil {
return nil, err
}
claims, err := jwt.EdDSACheck([]byte(token), []byte(key))
if err != nil {
log.WithError(err).Warn("jwt.EdDSACheck()")
return nil, status.Error(codes.Unauthenticated, "EdDSA verification failed")
}
if !claims.Valid(valid) {
log.WithError(errors.New(errExpiredToken)).Warn("jwt.EdDSACheck()")
return nil, status.Error(codes.Unauthenticated, errExpiredToken)
}
return claims, nil
}

Drop the adminlte submodule

At this moment adminlte is "imported" using a git submodule. It is around 83MB and largely unused. Instead, I'd prefer to keep only the minified css and js files in a central place and ditch the submodule.

Move the proto-buffer files to root

Currently the PB files are in the pb directory. However, the package definition is authenticator. This makes is impossible to import the generated package without alias. For instance, this breaks VS Code auto-imports and sometimes upsets the intellisence.

The files authenticator.proto and authenticator.pb.go will be moved to the root of the project to improve the situation.

Tokens in redirect URL need to be of short lifetime

Currently all tokens generated have a single configuration option for Expiration. If this is set to a high interval, it is possible to re-use a URL based token redirect and re-initiate a logged-out session.

Instead, redirected tokens should have a short expiration time. Refreshed tokens usually live in a client session, header or cookie and can have a longer interval. Therefore consumers will need to refresh their token upon the first opportunity after redirect.

The following things need a bit of refactoring:

  1. The authReply method should accept a time.Time instead of looking to the server config.
  2. AuthenticatePwUser and RefreshJWT gRPC methods should accept a time stamp, so the consumer decides the requirements.
  3. Adjust the admin login form to use short timeouts.

httpauth: Error on successs

Something seems to go wrong with the password reset success / confirmation screen.

500 Internal server error. While handling:
200 OK: Password request link sent

Logs:

authenticator_httpauth.1.o5mlan39h5fc@wrk0    | t=2020-07-05T12:39:59+0000 lvl=eror msg=EP.Render id=86efaa48f0 uri=/reset-password pkg=authenticator.forms handler=SetPW method=resetPWPost err="ehtml Render template: template: base.html:11:19: executing \"header\" at <.Data.SiteName>: can't evaluate field Data in type *ehtml.Data"

Swap logrus for clog15/log15

Clog15 is a utility package which attaches a log15 instance to a context. This make it easy for both gRPC and http servers to do request scoped logging. As a personal preference, I find log15 cleaner and easier to work with.

httpauth, forms and middleware are already built with this change in mind. The gRPC server and admin still need to be adapted.

This is a non-essential and long term cleanup effort. No deadline.

Middleware: Key not found returns Internal Server Error

At the moment, when a public key is not found an (incorrect) internal server error is returned to the client. gRPC already returns the correct "not found" class code, but it is unhandled by middleware.

Instead of internal server error, the client should be redirected for login.

Normally, public keys are never deleted from the database. New ones are just added at server start and older ones can always be obtained. Therefore, this bug is not very critical.

Update documentation

The newly added httpauth and forms required some expansion on documentation. The README also needs to be updated by this new feature set.

404 in relation view

Paths like ๐Ÿ•/groups/2/ and ๐Ÿ•/audiences/2/ result in a 404 without logs. This might be a router issue.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.