Allow using authentication service as a library

[chadfurman]

I'd like to pull in the backend and front-end js components separately. I have a GraphQL API and would like to write resolvers that use this service.

What do you think of making a monorepo (pnp-authentication) made up of the following packages:

• pnp-authentication-users - package that provides tools for authentication, account creation, and generating password reset tokens
  • emits events like "userRegistering", "userRegistered", "loginFailed", "resetTokenGenerated", ...
• pnp-authentication-email - a basic send-receive email package configured through the standard environment variables
  • "emailSendSuccess", "emailSendFailure", ...
• pnp-authentication-jwt - a package for creating and verifying JWTs
  • events could be used for implementing a JWT caching system
• pnp-authentication-avatar (image uploading, adding avatar data to schema)
  • default configuration to be compatible with existing schema expectations
• pnp-authentication-recaptcha - utilities to add and verify a recaptcha
• pnp-authentication-templates - Registers functions for generating templates
  • comes with the current set of template files

pnp-autnentication should allow for overiding any of these packages -- there should be a set API that these packages use to communicate, as well as a configure option when initializing the library to override any of the default API with a custom implementation.

Here is one theoretical way we could make this more of a configurable library while still staying true to the plug-and-play nature of the whole thing:

const authService = pnpAuthentication({
  jwt: {
    signJwt: function implementsJwtPackageApiForSignJwt(...) { ... },
    // other functions not mentioned here use the default from the package
  },
  templates: {
    login: renderLoginFuncion; // renderLoginFunction gets passed any config data needed to render the login page, and returns the complete HTML (CSS, JS, etc) necessary to render this view
  }
})

[gimenete]

Email and avatar are already implemented in other microservices.

My suggestion would be to split the code in these layers:

@clevertech/auth-core: the core library, with an interface for configuring the db layer.

import core from '@clevertech/auth-core'

core.setDatbaseAdapter(dbAdapter)

// API
core.login(...)
core.register(...)
core.forgotPassword(...)
core.resetPassword(...)
core.changePassword(...)
core.confirmEmail(...)
core.enable2FA(...)
core.disable2FA(...)
core.initRecoveryCodes(...)
core.useRecoveryCode(...)

@clevertech/auth-web:

• Exports an express router.
• Implements endpoints to be consumed by a regular API.
• Implements a regular web application (the current EJS + jQuery UI).
• Adds support for re-captcha.

That would be the current implementation split into smaller parts. Then we can implement others: REST, GraphQL, React components, etc.

[chadfurman]

@gimenete I like where this is going. Makes sense with auth-core to configure the db layer.

Could we further split auth-web? I want the 2fa and the oauth and the recaptcha and the email verification, but I don't want the templates or the routes. I also want parts of the JWT implementation.

It makes sense that auth-web puts them all together for ease-of-use. I suspect there is value in having this collection of components mix and matchable as well. Not only for different implementations, but also for ease of maintainence. extensability, and modularity.

[gimenete]

• For 2FA I'm using an existing library. So most of my code is putting things together.
• I'm not implementing oauth. I said the way the service works is like oauth (redirecting back to the main app when the signup/login/whatever is done).
• The JWT part is also very small. I'm using a library that itself already has generation/validation.

Another thing I missed that can be pluggable is third-party auth systems (facebook, google,...).

[chadfurman]

I'm not implementing oauth. I said the way the service works is like oauth (redirecting back to the main app when the signup/login/whatever is done).

I understand this. That said, the pnp-oauth module I suggest would be for the third-party auth systems that you've mentioned.