This PR introduces gRPC support with Protobuf.

Closes #78

Continuous feedback is preferred instead of waiting for me to finish.

Tasks:

• [x] refactor existing code so it can be reused more readily between HTTP and gRPC servers
• [ ] remove the current server into authn-server/http
• [x] work on a parallel authn-server/gRPC package that can be preferred with a command flag
• [ ] if and when appropriate, bring in grpc-gateway to replace the authn-server/http package
• [x] protect the gRPC API from abuse (existing REST API validates Origin header, gRPC does .... [insert something here])
• [ ] tests, tests, tests
• [N/A] Fix mTLS with with cmux & add tests for it (I feel this is going to be a giant test)
• [x] Address comments here. It's pretty tricky to eliminate dependency on vendor directory.

Critical bug in current branch:

• [x] mounting on a subpath not working. My hunch is wrapping the handler with http.StripPrefix should fix it, but I'm yet to tackle it.
• [x] Work around this "bug".

Resources used and/or might need as reference to complete PR:

• So you want to use GoGo Protobuf
• Authentication in gRPC
• HTTP server from gRPC with Gateway
• gRPC-Gateway Error Handler
• Advanced gRPC Error Usage
• Workaround to marshal application/x-www-form-urlencoded w/ grpc-gateway
• https://github.com/grpc-ecosystem/go-grpc-prometheus

Fixes #68

@egorsmkv Please try https://github.com/keratin/authn-server/releases/download/v1.4.1/authn-windows64.bz2 and let me know how it goes!

• [x] Change dist naming so the upload to GH is less error-prone
• [ ] Extract port from AUTHN_URL
• [x] Active users page 404
• [ ] Support for authn-server.env file

Hi there, I'm getting the following error when trying to run the AuthN docker image on EC2 Ubuntu 20.04.

~*~ Keratin AuthN v1.10.4 ~*~
data.NewDB: dial tcp: lookup <redacted>.us-east-1.rds.amazonaws.com: device or resource busy

I have a fairly simple setup, just an EC2 instance and an RDS instance. I have done the following debugging and am quite certain that it is not a networking issue like security groups.

1. On the EC2, I can psql to the RDS instance
2. I used docker exec to run the AuthN container, installed psql using apk --update add postgresql-client and was able to successfully connect to rds
3. There is a dockerized Rails app on the same EC2 that can reach the same RDS instance
4. The docker-compose below works fine on my local machine (mac) but causes the above error on EC2

Here is my docker-compose (sensitive items removed)

version: '3.8'
volumes:
  redis_auth_data:

networks:
  frontend:
  backend:

services:
  redis:
    image: redis
    # using persistant storage
    command: ['redis-server', '--appendonly', 'yes']
    volumes:
      - redis_auth_data:/data
    networks:
      backend:
        aliases:
          - redis_auth.docker # used below

  keratin_auth:
    image: keratin/authn-server:1.10.4
    ports:
      - "21002:3000"
      - "21001:21001"
    environment:
      - AUTHN_URL=http://localhost:8080
      - APP_DOMAINS=localhost
      - HTTP_AUTH_USERNAME # passthrough from env
      - HTTP_AUTH_PASSWORD # passthrough from env
      - DATABASE_URL=postgresql://<pg_username>:<pg_password>@<host>.us-east-1.rds.amazonaws.com/keratin_authn
      - PUBLIC_PORT=21001
      - REDIS_URL=redis://redis_auth.docker:6379/1
      - SECRET_KEY_BASE=<redacted>
    networks:
      backend:
      frontend:
    depends_on:
      - redis

Thanks in advance

I found an issue that caused me confusion. First I thought that it was a front-end issue, but it is in the back end, and the front end will report success even though the passwords are different.

To reproduce:

Step 1 Sign up using credentials: Username: User1234 Password: 9oiajshdfioudewiuufjhi8127y4981

Expect: Token (201) Result: Token (201)

Step 2: Sign up using credentials: Username: User1234 Password: sometotallydifferentPassword1897387214

Expect: TAKEN Result: Token (201)

Maybe it is the way I have set this up but it feels a bit slow. I did some testing from a pod in the Kubernetes cluster and checking if a user already exists on register varies between 300ms and as high as 2 seconds. That feels very slow for a Go application.

Hey Lance and all contributors!

First of all, thanks so much for this project, looks really good. So I gave the server a spin and started testing some stuff. I specifically set USERNAME_IS_EMAIL=true and then created an account using the signup endpoint, using my GMail address for that. All good.

Then I tried logging in using OAuth and Gmail, but got access deined because that account already existed. I would expect to be able to log in using OAuth and Gmail, since I am the owner of my account. Shouldn't this be the expected behaviour?

Please correct me if I completely misunderstood the way id_tokens should work in Authn, but I have some concerns about them from what I have seen so far:

What

Currently when signin in, signing up, refreshing, and in every other endpoint where this happens, an id_token is returned from these requests. Giving a client - in this case, specifically a webbrowser client - the option to read the id_token (which is a signed token) and storing it somewhere (like in local storage or cookies) opens up XSS attack possibilities.

Proposal

Instead of returning the id_token, I would suggest returning only the JWT claims in a plain JSON object (without a signature, so it can't be used as an id_token), so that frontends are still able to know when to refresh the token when validity halftime is reached. Then, also set a cookie from Authn Server that has the HttpOnly flag set to true, so that it can't be read via javascript and which will be automatically sent by the browser on every request made to the backend or other backends in a microservices architecture, for instance. However, this would mean every client library will also have to be adapted to this new implementation and would mean breaking changes :sweat:

Or maybe there is another way?

How can i signup user from my backend ?

response is  'Origin is not a trusted host.' 
 Error: Request failed with status code 403

When i do POST request to /accounts with username and password i get error.

Also which url should i use to perform signup from backend AUTHN_URL? Or same as i do from browser?

for example now getting the user from my backend is working like http://HTTP_AUTH_USERNAME:HTTP_AUTH_PASSWORD@authn:3000/accounts/${userId} but performing POST for signup from backend caused error

Idea

We'd like the ability to have our server side application send newly created accounts an email to create a password. This is 99% the same as a reset password flow, except that 1) it is triggered by our server and 2) we need to send a different email which means we need the AuthN server to hit a slightly different endpoint than reset password

Changes API

1. Create a new private endpoint that behaves identically to the current reset password endpoint. Potentially /account/invite
2. Add a new env var APP_INVITE_URL that would be the uri of the server to call to deliver the a "invite" aka reset password token

Thoughts/Feedback?

Thanks,

Doug

Hello @cainlevy

Thank you for all your work. I wanted to experiment with keratin and potentially use keratin in my hobby projects. I use terraform and helm to configure my playground and I was a bit upset to know that there are no helm charts available for it. I also wanted to learn about helm a bit more so I created charts for helm version 2 and 3 here: https://github.com/obukhov/keratin-helm-charts

I tested them and they seem to work although there is probably plenty of space for improvements. I created helm repo with github pages, so potentially anyone can use it: https://github.com/obukhov/keratin-helm-repo

I was considering to create a PR to add by repo to helm hub (like described here: https://github.com/helm/hub/blob/master/Repositories.md). But before that, I wanted to discuss with you the following question: I think it would make much more sense if these two repos will be moved to keratin organization - it will be easier to discover them and contribute for the others and also help to get rid of "bus factor".

I also haven't used any keratin related images in the charts (like icon/logo) because I wasn't sure this is allowed.

Let me know what you think about that.

Main focus is on ability to pass Docker secrets properly instead of environment variables.

If Secure settings are not set, then drop to original mode of loading secrets from environment variables.

Other minor changes:

• App name and version are printed as 1st line on startup to to make sure app is starting
• Added Docker version tags
• removed routing.go from Makefile, because it does not seem to exist (could it be the reason for runtime error I reported?)

Version with these changes is on my Docker space https://cloud.docker.com/repository/docker/kulak/authn-server

Hi --

We've been using Authn (both authn-server and authn-js) for several years. We've discovered an issue (which is frustratingly vague), whereby users on our PWA on mobile find they have to log in too much. We had not changed the configuration for either the ACCESS_TOKEN_TTL or the REFRESH_TOKEN_TTL, so my understanding is that users should remain logged in for 30 days, with authn-js automatically attempting to refresh their access token at the half life (which would be every 30 min).

The refresh attempts appear to be failing with a 401, somewhat reliably, in the PWA after about a day or a period longer than 1 hr -- I'm not exactly certain how long it takes for it to happen as I haven't been able to reliably reproduce the issue. I don't know for sure, but I don't think it matters if the user closes out of the app, or merely minimizes it and uses other applications on their phone. However, I do think that if our PWA were open on their phone, the refresh logic would work, but something about minimizing it or having it go "dormant" seems to cause an issue.

There was a bit of documentation for the /session/refresh route that potentially seemed relevant:

As long as a device remains logged in to the AuthN server, it can hit this endpoint to fetch a fresh JWT session. The [keratin/authn-js](https://github.com/keratin/authn-js) library can automate this by preemptively refreshing tokens when they reach halflife.

Is the mobile device not remaining logged in to the AuthN server and that's causing the problem? If so, is there a way to prevent its disconnection?

I'm also wondering if this could be an issue related to switching networks or losing connectivity in general, though it seems like AuthN should still be able to refresh the token after losing connectivity, so long as the refresh token were still valid.

It seems improbable that the refresh tokens themselves are expiring, given they are supposed to be good for 30 days -- so I'm also wondering if there are other reasons for the refresh attempt to fail with a 401 that might have to do with timeouts, etc.

Versions of AuthN:

• authn-js: 1.3.0
• authn-server: 1.10.2

Example of failing request (from logs in Heroku):

• "GET /session/refresh HTTP/1.1" 401 0 "https://frank-staging.netlify.app/home" "Mozilla/5.0 (iPhone; CPU iPhone OS 15_6_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.6.1 Mobile/15E148 Safari/604.1"

AuthN is alive! It handles its scope of responsibility quite well and is deployed into multiple production environments. I'm still able to coordinate and guide contributions and manage releases.

Nonetheless, I'm seeking an additional maintainer who can increase the bus factor and bring new energy to the project. If you are interested, please reach out to lance-at-cainlevy-dot-net with some brief detail about your experiences with AuthN and your vision for how you'd like to continue moving it forward.

I have SSR logic that hydrates the page data based on user-id, so it needs to authenticate the user from the initial request's cookie.

Currently, my authn-service instance's login and register endpoints return the id-token in the response payload, so I have to set it in localstorage.

Is there a way to configure authn-server so that those endpoints set the id-token in the cookie?

Keratin supports generic OAuth2 providers here: https://github.com/keratin/authn-server/blob/master/lib/oauth/provider.go

However, there is no means to read configurations from the environment, or otherwise inject them. The credentials, scopes and endpoints required for an *oauth2.Config could be represented by:

CUSTOM_OAUTH_NAME (Used for HTTP path.) CUSTOM_OAUTH_CREDENTIALS CUSTOM_OAUTH_AUTH_URL CUSTOM_OAUTH_TOKEN_URL CUSTOM_OAUTH_SCOPES

Or, the env vars could be written to be easily pattern matchable to allow for multiple custom providers.

I see there are outstanding requests for Twitter and other providers. A generic provider would sidestep the need to PR for every requested provider. I believe the oauth2 library took the same tack and basically stopped accepting changes for what amounted to config as code: https://github.com/golang/oauth2#policy-for-new-packages

Is there a way to rather store the account ID or user ID as UUID instead of integers? I worry about iterating over integers where we would have to separately map UUID to an account/user.