Light OAuth2

Light follows a security-first design. Given the complexity of microservices architecture, there is no existing OAuth 2.0 provider on the market that is suitable for microservices. Most commercial products focus on the perimeter and don’t have solutions for service to service communication inside the corporate network. This is the reason we have provided an OAuth 2.0 provider light-oauth2, which is based on light-4j and light-rest-4j frameworks. The light-oauth2 consists of 7 microservices that can be deployed in one cluster with multiple instances of token and code services and one instance of other services. Or you can deploy two clusters if your organization needs one cluster for external clients and another cluster for internal clients.

The light-oauth2 is not just an OAuth 2.0 provider. Some of the services implement the OAuth 2.0 specifications. Others implement some extensions to make OAuth 2.0 more suitable to protect service to service communication regardless of request/response (light-rest-4j, light-graphql-4j, and light-hybrid-4j) or event-driven (light-kafka). It has entitlement management built-in to support scope verification at the endpoint level for services with JWT. It also can be federated to support multiple clusters in the same organization or across multiple organizations. The key distribution architecture enables resource servers to pull public key certificates that are used to verify JWT from the OAuth 2.0 provider key distribution service instead of the traditional push approach.

Why this OAuth 2.0 Provider

This is a unique product that is designed for microservices as microservices. It has more features than what are described in popular OAuth 2.0 related specifications. To learn more about the attributes of this product, please refer to why this OAuth 2.0 provider.

Getting started

The easiest way to start using light-oauth2 in your development environment is through docker-compose in light-docker repository. Please refer to getting started for more information. If you don’t want to run light-oauth2 locally, you can use our [cloud services][]for development.

Architecture

There are some key decision-making points that are documented in the architecture section. It adopts microservices architecture which set itself apart from other OAuth 2.0 providers on the market.

Documentation

The detailed API document helps users to understand how each individual service works and the specification for each service. It also contains information on which scenarios will trigger what kind of errors.

Tutorial

There are tutorials for each service that show how to use the most common use cases with examples. It includes some typical deployment scenarios to help users to implement OAuth 2.0 in-house.

Reference

There is a vast amount of information about OAuth 2.0 specifications and implementations. Here are some of the references that can help you to understand the OAuth 2.0 Authorization.

Deployment of light-oauth2

There are numeric options to deploy light-oauth2 and sometimes it is overwhelming as there are too many options for the microservices based OAuth 2.0 provider. The most popular one is to deploy all services to a Kubernetes cluster or Openshift cluster which is almost the same as vanilla Kubernetes. Deploy to Kubernetes Secure HazelCast Read More »

Authenticator

For every organization, there will be a lot of different authentication/authorization mechanisms in use. For example, Kerberos/SPNEGO SSO will be used for employee and a customer database will be used for customers. In a big organization like a bank, almost every client application will have its own auth mechanism. This requires that OAuth 2.0 providers support customization and to plug in different authentication/authorization providers. Most of the commercial products don’t have source code available, and it requires to manipulate security policies to do any customization. Read More »

Reference

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 supersedes the work done on the original OAuth protocol created in 2006. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This specification and its extensions are being developed within the IETF OAuth Working Group. Specifications OpenID Connect Core 1.0 incorporating errata set 1 - OpenID Connect core OAuth 2. Read More »

Introduction

OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user’s resources on an HTTP service - normally exposed as a REST API. It works by delegating user authentication to an authorization service which contains all sorts of login service providers like LDAP for employees and database for customers. OAuth 2.0 provides authorization flows for the following types of application to application communication: Web server to API Standalone application to API API to API This informational guide is geared towards application developers and provides an overview of OAuth 2. Read More »

Architecture

Unlike web services where all services are built into a monolithic application and we can put a gateway in front of the application for security, the service to service communication adds a lot of overhead if we go through a gateway. We also cannot go to the OAuth 2.0 provider to get token or verify token for each request due to the dramatically increased volume. The following are some of the architectural considerations for the microservice OAuth 2. Read More »

Services

OAuth 2.0 provider has a list of services that cover standard OAuth 2.0 grant flows and extended features like service on-boarding, client onboarding, user management, token exchange, token chaining, scope calculation, federation and public key certificate distribution. This document only describes the features and processes of each service. Please refer to tutorial on how to access these services. Authorization Code - Authenticate to OAuth 2.0 and get authorization code SPNEGO/Kerberos - Authenticate to OAuth 2. Read More »