Effing Better Auth with Oauth2 for ELK

Don’t be misled by the title. You may be thinking, “Finally! Instructions on how to implement Oauth2 with X-pack.” Ok, it is about that, but first you should know that there is no support for Oauth2 with X-pack. Stop looking for it. This is about how you implement it yourself the hard way. Strap in folks. This is going to be a ride for the ages.

I encountered this problem personally and I could not find any solution in forums, documentation (Ha!), or blogs. I really looked a lot and hard. The best I could find are some forum posts that were closed with no resolution and X-Pack with OAuth Authentication which led me to this gem Integrating with Other Authentication Systems

Those are just for reference. Observe and familiarize yourselves with the contents, but believe me when I say,

These are not the droids you are looking for

Some of you may be reading this and hadn't yet come across the links given above. Some of you already have and arrived at the same conclusion as I have. If you are already familiar with the problem, just skip to the answer. If you are new this issue and need some explanation or at least some convincing about the solution, read on.

Oauth2 Refresher

Before getting to the real meat of things, we first need to understand (big picture) how OAuth2 works and how it fits in with X-Pack and the ELK stack.

Rather than get into technical details an history of what OAuth2 is and why to use it, I'm going to go straight into the flow to illustrate what exactly is happening during OAuth2 authentication process.

OAuth2 is Not Authentication

OAuth2 flow is actually what occurs after authentication. Authentication is the process of being challenged for credentials (a login screen), then verifying those credentials. Oauth2 does not use standard credentials. Access is managed through a session token.

OAuth2 Flow

Due to the nature of the web OAuth2 is connection-less. That is, it isn't something that just stays open like a VPN. Instead, numerous requests and responses are made for verification. This is referred to as the oauth2 flow.

Auth Initialization request an oauth2 auth from the application to be accessed. The auth request usually consists of (grant type, code, and request uri)
Authentication this is actually outside of the Oauth2 flow, but we are going to start here. Normally, you authenticate some way (Oauth2 is not authentication, it's for authorization).
Start flow now that authentication is complete flow begins.
Client Verification Request is what the application will now try to do. It will actually send a request back to the client (Note: Remember this part. It will be important later.). The request contains a code (the same one sent from the client originally to the oauth2 provider.)
Client Verification Response will now take the same code given in the previous step and compare it against the code that was sent.
Token Request once the code is verified and everyone agrees they are who they say they are (sounds like some shady backroom deal), the application will request a token from the Oauth2 provider. It will make a request with the client id, client secret, credentials type, and scope as parameters for the token. The client id and client secret are specific to the application. The user has no notions about what this is or what it's for. It is kept hidden from the user.
Token Response the Oauth2 provider will not respond back to the client with an access token as part of the response payload. This token can be used within a Authorization: Bearer HTTP header to whatever service within the Oauth2 domain that it needs access to. This token can be saved to the client session, and reused as long as the user remains logged in.

X-Pack: How it works

Now that we understand a bit how OAuth2 works, let's have a look into X-Pack and see exactly why these two are in conflict.

X-Pack Resides in Elasticsearch

X-Pack is actually a plugin for Elasticsearch. X-Pack has its own set of extensions that can be installed; however, it is basically just Elasticsearch. That means it runs within Netty and produces/consumes HTTP requests.

For reference, here is a link to the X-Pack Security API. From the examples, you can see that logging in with X-Pack is as simple as _xpack/security/_authenticate. Unlike OAuth2, it is only one request. X-Pack only supports Basic Authorization which means you simply make a GET request with the Authorization: Basic header. If your response is anything other than status 200, it failed authentication. Pretty simple.

Too Simple

This is exactly why it cannot work with Oauth2. The normal login process for kibana is a user provides Username/Password credentials at a login screen. Instead of POST of this information to a form

A REST request is sent to (not X-Pack) Kibana containing the Username/Password credentials
Kibana's builtin X-Pack client then sends a request to X-Pack for authentication at _xpack/security/_authenticate
The response is handled and authz details are then stored in session state
Kibana then re-requests the / main page which loads session data and skips the login

To recap The login page doesn't make a POST. Instead it makes a REST call, then reloads the main page. This is important because it does not follow a flow. It just loops itself. It's also important to note that a REST call is what's actually authorizing. This means, the login page basically throws auth over a wall and waits to see if anything gets thrown back.

^^ EXACTLY WHY OAUTH2 CAN'T WORK

Read on for more details.

OAuth2 is for Client/User Authorization

That is, it requires a user on one end to provide information. You can do just server-to-server authorization; however, we are trying to add OAuth2 to kibana. It will not serve use to user server-to-server.

Some solutions actually suggest this as an answer by layering impersonation on top of that. How does server-to-server authz with user impersonation not sound like absolute h4x0ry? It's just silly. Let's pretend we didn't hear that silliness and try to do things correctly just this once.

X-pack is for Service Authentication and Authorization

X-Pack handles simple credentials over HTTP because it's assuming communication from another service (like the X-pack client embedded into kibana).

It can't work because

X-pack is Authentication and Authorization (Oauth2 is just Authorization)
Kibana has no way to get a response from X-pack other than the session.
Third-party auth providers (SSO for example) cannot gain access to X-pack
OAuth2 flow requires redirect to the Authentication provider for user input
OAuth2 flow requires client verification by sending a request back to a redirect uri
OAuth2 flow returns an authorization token in the HTTP response (not a cookie)

The Answer

Ok, now that we're all familiar with the problem... It seems hopeless, right? It's not. The solution is actually very simple. Here's why:

Kibana is built on HapiJS

HapiJS is a web application toolkit created by the folks at Walmart Labs. It comes with a plugin (Kibana is actually using it for auth) called Bell for Authorization and Authentication. It's rather brilliant. Most importantly, it supports OAuth2 out-of-the box. This is great because you can write a plugin for Kibana that instantly will hook you up with Oauth2.

What about X-pack?

This is actually very simple. We just make our Oauth2 plugin an X-pack client. Now upon completing the Oauth2 flow, we can authenticate with X-pack. I will explain how, but first we will tackle the Kibana Plugin.

Here it is