Repository files navigation

Stack Overflow |Google Group |Gitter Chat |Subreddit |Youtube Channel |Documentation |Contribution Guide |

Light platform follows security first design and we have provided an OAuth 2.0 providerlight-oauth2 which is based on light-4j and light-rest-4j frameworks with 7 microservices.Some of the services implement the OAuth 2.0 specifications and others implement someextensions to make OAuth more suitable to protect service to service communication, otherstyles of services like GraphQL, RPC and Event Driven, Key management and distribution,service registration, token scope calculation and token exchange.

It can support 60000 user login and get authorization code redirect and can generate700 access tokens per second on my laptop.

It has 7 microservices connected with in-memory data grid and each service can bescaled individually.

OAuth 2.0 is just a specification and a lot of details are in the individualimplementation. Our implementation has a lot of extensions and enhancementsfor additional security and prevent users making mistakes. For example, wehave added an additional client type called "trusted" and only this type ofclient can issue resource owner password credentials grant type.

You can deploy all services or just deploy the services for your use cases. You candeploy token and code service to DMZ and all others internal for maximum security.You can have several token services or deploy token service as sidecar pattern ineach node. You can start more instance of key service on the day that your publickey certificate for signature verification is changed and shutdown all of the butone the next day. You can take the full advantages of microservices deployment.

• Built on top of light-4j and light-rest-4j
• Light-4j Client and Security modules manages most of the communications with OAuth2
• Support service on-boarding from light-portal
• Support client on-boarding from light-portal
• Support user management from light-portal
• Open sourced OpenAPI specifications for all microserivces

The OAuth2 services can be started in a docker-compose for your local development andcan be managed by Kubernetes on official test and production environment. It exposesRESTful APIs and can be access from all languages and applications.

Out of the box, it supports Mysql, Postgres and Oracle XE and H2 for unit tests. Otherdatabases can be easily added with configuration change in service.yml.

With distributed security verification, JWT signature public key certificates mustbut distributed to all resource servers. The traditional push approach is notworking with microservices architecture and pull approach is adopted. There is akey service with endpoint to retrieve public key certificate from microservicesduring runtime based on the key_id from JWT header.

Each service in a microservices application needs a subject token which identifies theoriginal caller (the person who logged in the original client) and an access tokenwhich identifies the immediate caller (might be another microservices). Both tokenswill be verified with scopes to the API endpoint level. Additional claims in thesetokens will be used for fine-grained authorization which happens within the businesscontext.

Even with two tokens, we can only verify who is the original calller and which client isthe immediate caller. For some highly protected service like payment or fund transfer,we need to ensure that the call is routed through some known services. light-oauth2token service support token exchange and chaining so that a service can verify theentire call tree to authorize if the call is authorized or not.

light-oauth2 has a service registration to allow all service to be registered with serviceid and all endpoints as well as scopes for the endpoint. During client registration, youcan link a client to services/endpoints and the scope of the client can be calculatedand updated in client table. This avoids developers to pass in scopes when gettingaccess token as there might be hundreds of them for a client that accesses dozens ofmicroservices.

A database audit handler has been wired into all light-oauth2 services to log eachactivity across services with sensitive info masked. In the future we will put theselogs into AI stream processing to identify abnormal behaviors just like normal servicelog processing.

light-java to build API

light-oauth2 to control API access

light-portal to manage clients and APIs

Thisintroduction document contains all the basic concept of OAuth 2.0 specification and how it work in general.

The easiest way to start using light-oauth2 in your development environment is throughdocker-compose in light-docker repository. Please refer togetting started for more information.

There are some key decision points that are documented inarchitecture section.

The detailedservice document help users to understand how each individual serviceworks and the specification for each services. It also contains information on which scenarios will trigger what kind of errors.

There aretutorials for each service that shows how to use the most common use cases with examples.

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