keratin/authn

Prototype version of AuthN service. See: keratin/authn-server

authn's Issues

Account Security Event Logging

Keeping an audit trail of successful logins and password changes for an account would allow an application to show the end-user their security event history. This allows an end-user (or a support team) to investigate suspicious activity.

Multi-Factor Authentication

Support for Google Authenticator-style MFA, plus the ability to require MFA for all accounts.

require existing password to change password with session (not reset flow)

When changing a password using the session, Keratin AuthN should require the existing password. This is standard practice to prevent someone from getting locked out of their account if they walk away from an unsecured computer.

Remove non-printing characters from username

Lookalike username attacks can be used for social engineering situations like phishing.

500 error with invalid session JWT

authn_1  | JSON::JWS::VerificationFailed (JSON::JWS::VerificationFailed):
authn_1  |
authn_1  | app/models/session_jwt.rb:14:in `decode'
authn_1  | lib/authn_session.rb:26:in `authn_session'
authn_1  | app/controllers/sessions_controller.rb:37:in `refresh'

Authenticated Password Changes

Users should be able to change passwords without going through the email process. This should only work if they have an active AuthN session.

Account Archival

Ability to permanently archive (aka delete) an account, freeing up the username and deleting all sensitive or private information.

Heuristic-driven MFA Challenges

An additional MFA option to require that accounts pass additional MFA challenges when heuristics determine that the access is "unusual".

BCrypt Cost Migration

When choosing to increase the BCrypt work factor, a person should be able to walk the database and increase the work factor of all stored hashes without waiting for a next login.

Countermeasures for Scripted Signups

Throttles are not enough to fight a distributed attack on the signup process. This feature adds support for advanced countermeasures that make scripted signups costly and difficult, without resorting to CAPTCHA.

Throttling for Abusable Endpoints

Throttling for every endpoint that leaks information about users in the system or can be used to incur costs to the business (e.g. SMS). A well-designed throttling plan should leave normal users unaffected while slowing and eventually auto-banning attackers.

Make redirect-on-logout configurable

XHR/fetch will follow the redirect on the front end, creating a page refresh. We should be able to programmatically handle the outcome of a logout (e.g. by nulling out the user reference on the frontend).

Disable Signups

Users may want to freeze their account list or provision accounts separately, e.g. through invites. This setting should disable both the signup and username availability endpoints.

Account Device Management

Track all devices connected to an account, and provide endpoints that then application can integrate to provide end-users with the ability to review and revoke any connected device.

no json errors when destroying unknown account

The 404 Not Found status may be sufficient, but an accompanying "account": "ACCOUNT_NOT_FOUND" would be more consistent.

provide better dev feedback for missing configuration

The config/initializers/app.rb file provides a passable experience for folks who enjoy following stack traces to discover code comments, but no one else. Parsing out ENV variables should provide a better dev experience with clean errors and wiki links for missing variables.

Single Sign-On

Enable SSO across multiple applications and domains, and ensure that signing out from one location will also sign out all other locations.

key rotation

The AuthN server should be able to rotate keys. This means keeping old keys around long enough to verify existing JWTs while signing new JWTs with the new key. The trick will be figuring out an appropriate waiting period for refresh tokens.

Also see: http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys

Twilio MFA

Support for SMS-based MFA using provided Twilio credentials. Includes support for formatting and verifying a number.

Different from #10 because it actually implements delivery process and removes need for app to integrate Twilio itself.

Domain-restricted account creation

Restricting sign ups to an organizational domain means validating usernames and also implementing an email verification step. Half of that is a feature and the other half is a HOWTO.

Passwordless Login Links

Password-less login links can be delivered by trusted channels such as emails or native app push notifications. The page where a user initiated the process can poll for updates and proceed immediately once the login link has been activated.

Next-login Enforced Password Change

Ability to flag accounts as potentially compromised and require them to go through a reset process on their next login attempt.

Account Locking

Ability to lock an account, such that the login name remains claimed but can no longer be authenticated or reset.

Ability to unlock.

Rewrite into Go or Rust

At some point performance will become more important than ironing out the early featureset. That's the right time to learn and rewrite into Go or Rust. The AuthN service should be able to do a lot with little hardware.

configurable BCrypt cost

Consider making the BCrypt cost configurable but impose a minimum cost.

It shouldn't be commonly needed, but it's easy to make available.

support routing path prefixes for path-based microservice routing

Some deployments may require a single domain to proxy between multiple services based on Layer 7 path matching. Amazon's ALB supports this, for example.

In order for AuthN to work in this scenario, it needs to knows its full base URL (including path) and match routes accordingly. It also needs to ensure that the refresh token cookie is scoped to the correct path.

The Ruby and JavaScript clients will also need to be updated to ensure the base path is included in URLs.

The JavaScript client should not yet worry about base URL issues in the application cookie store.

Advanced Password Policies

Advanced password policies for required rotation intervals, history-driven reuse requirements, or other rules that may be important to an organization.

Email/SMS-based MFA

Generate and deliver a MFA code suitable to be delivered by application emails or SMS and typed by hand.

Social Provider Logins (Facebook, Google, etc)

Keratin AuthN could remain focused entirely on username/password credentials (aka owned accounts) or it could expand to include connections to third-party accounts from Facebook, Google, Microsoft, GitHub, and similar.