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
- Getting started
- Authorization Code - Authenticate to OAuth 2.0 and get authorization code
- SPNEGO/Kerberos - Authenticate to OAuth 2.0 with SPNEGO/Kerberos
- Token Endpoint - Token endpoint of OAuth 2.0 provider
- Signing Endpoint - Securely exchange information between microservices
- Service Registration - Service registration endpoints
- Client Registration - Client registration endpoints
- User Management - User management endpoints
- Key Distribution - Public key certificate distribution
- Refresh Token - Refresh token service
- Provider Registration - Oauth provider server service
- Custom grant type - Client authenticated user grant type
- PKCE PKCE implementation
- OpenID Connect OpenID Connect implementation
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.
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.
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.
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.
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.
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.