Background

Why OAuth2?

It does authentication and enables authorization in a standardized way, which is the current standard (Google, Facebook, Github, ...).

More precisely it enables us to secure all our APIs against forbidden actions like unauthorized deletion and simple attacks like heavy API usage plus to make group and user based restrictions. (rate limiting, bot detection, role restrictions)

Thus JWT is replaced. But if services need more user information than OAuth/Kong provides, we could still use JWT for specific routes.

How?

The main idea was to exchange the current proxy from JWilder with Kong.

Details:

• introduce Kong with Lets encrypt (Kong and our own docker container kong-companion)
• define public APIs (not in code - making a plan)
• define usergroups (not in code - making a plan)
• configure Kong
• write OAuth2 Hapi plugin which handles the headers and provide the userdata in an easy way plus could be enabled via a route option. Should also detect the public OAuth user and return unauthorized if the route is secured.
• update all services (use hapi plugin)
• Define and provide a developer environment

Status?

• Kongs version is 0.13 which seems to work.
• kong-companion is a working version and needs an empty Kong configuration in order to work. (services and routes should only be changed by kong-companion) More testing and bugfixing is needed here. (ongoing on *.slidewiki.de)
• Which routes should be public and where group restriction should be enabled is not defined yet (a few basic decisins and then each service maintainer have to decide on her/his own. Kong is still in development, but atm a public OAuth2 user is configurable, scopes have no use and the services will only get user and group information which they have to handle by themselves.
• The Hapi plugin does not exists yet, but its a small one.
• Updating a service is easy but could cost a few hours, depending on the service size.
• Developer environment not defined yet

When everything is ready it has to be introduced on experimental and later on the other servers. This will also be work.
In general this is manageable to be done this year. The problem is that major tasks have a higher priority and thus service maintainers will take their time to update their services. But in order to deploy Kong/OAuth, all services which are already using JWT have to be deployed in the updated version with Kong at once. Also the development environment have to be changed for each developer which makes introducing Kong a big task with a lot of coordination.

Miscellaneous

Kong has the following advantages:

• OAuth2
• JWT
• Group mapping
• Load balancing
• Rate control
• Logging
• Basic bot detection
• Dynamic IP blocking
• Built-in scalability

It missed automatic docker container detection and lets encrypt certificate management, which was added by Kurt with a docker container: https://github.com/slidewiki/kong-companion

In order to connect it in the correct way with Google and Github we need to use OpenID Connect with OAuth2 but this is an enterprise feature of Kong. This is relevant when we have OAuth.

Action items

• Should we introduce OAuth or keep it as an idea?
•