@microloop/authentication-service v1.8.1

authentication-service

Overview

A Loopback Microservice for handling authentications. It provides -

• Multi-Tenant support, you can see the database schema here.
• External Identity Provider integration.
• Ability to issue JWT tokens using jsonwebtoken.
• Authenticate JWT tokens using passport-http-bearer.
• Local Signup using a signup token.
• Forgot/Reset/Change password.
• Google OAuth using passport-google-oauth.
• Keycloak OAuth using passport-keycloak-bearer.
• Instagram OAuth using passport-instagram.
• Facebook OAuth using passport-facebook.
• Apple OAuth using passport-apple.

To get started with a basic implementation of this service, see /sandbox/auth-basic-example.

For a more elaborate and custom implementation that overrides the default models and repositories, see /sandbox/auth-multitenant-example.

Working and Flow

This module uses the decorators provided by @bleco/authentication and @bleco/authorization. For reference, below is the flow for the login code generation that uses to authenticate client, authenticate user and authorization decorators from these npm packages -

Installation

npm i @microloop/authentication-service

Usage

• Create a new Loopback4 Application (If you don't have one already) lb4 testapp
• Install the authentication service npm i @microloop/authentication-service
• Set the environment variables.
• Run the migrations.
• Add the AuthenticationServiceComponent to your Loopback4 Application (in application.ts).

  // import the AuthenticationServiceComponent
  import {AuthenticationServiceComponent} from '@microloop/authentication-service';
  // add Component for AuthenticationService
  this.component(AuthenticationServiceComponent);

• Set up a Loopback4 Datasource with dataSourceName property set to AuthDbSourceName. You can see an example datasource here.
• Set up a Loopback4 Datasource for caching tokens with dataSourceName property set to AuthCacheSourceName.
• Bind any of the custom providers you need.
• Start the application npm start

Environment Variables

Setting up a DataSource

Here is a sample Implementation DataSource implementation using environment variables and PostgreSQL as the data source. The auth-multitenant-example utilizes both Redis and PostgreSQL as data sources.

import {inject, lifeCycleObserver, LifeCycleObserver} from '@loopback/core';
import {juggler} from '@loopback/repository';
import {AuthDbSourceName} from '@microloop/authentication-service';

const config = {
  name: AuthDbSourceName,
  connector: 'postgresql',
  url: '',
  host: process.env.DB_HOST,
  port: process.env.DB_PORT,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_DATABASE,
  schema: process.env.DB_SCHEMA,
};

@lifeCycleObserver('datasource')
export class AuthenticationDbDataSource extends juggler.DataSource implements LifeCycleObserver {
  static dataSourceName = AuthDbSourceName;
  static readonly defaultConfig = config;

  constructor(
    // You need to set datasource configuration name as 'datasources.config.Authentication' otherwise you might get Errors
    @inject('datasources.config.authentication', {optional: true})
    dsConfig: object = config,
  ) {
    super(dsConfig);
  }
}

Migrations

The migrations required for this service are processed during the installation automatically if you set the AUTH_MIGRATION or BLECO_MIGRATION env variable. The migrations use db-migrate with db-migrate-pg driver for migrations, so you will have to install these packages to use auto-migration. Please note that if you are using some pre-existing migrations or database, they may be effected. In such scenario, it is advised that you copy the migration files in your project root, using the AUTH_MIGRATION_COPY or BLECO_MIGRATION_COPY env variables. You can customize or cherry-pick the migrations in the copied files according to your specific requirements and then apply them to the DB.

Database Schema

Providers

You can find documentation for some of the providers available in this service here

Common Headers

Authorization: Bearer where is a JWT token signed using JWT issuer and secret. Content-Type: application/json in the response and in request if the API method is NOT GET

Common Request path Parameters

{version}: Defines the API Version

Common Responses

200: Successful Response. Response body varies w.r.t API 401: Unauthorized: The JWT token is missing or invalid 403: Forbidden : Not allowed to execute the concerned API 404: Entity Not Found 400: Bad Request (Error message varies w.r.t API) 201: No content: Empty Response

API Details

Visit the OpenAPI spec docs