Proposal to Change PEPhub Authentication

[nleroy917]

Background

Overview of authentication

I am proposing that we make a slight modification to our authentication implementation currently in use on PEPhub. Today, there are two main methods web developers use to manage the question of authentication - who am I? - and the question of browser sessions - how long do I have to make authorized requests after I proved who I am?. These two methods are what I call the Traditional Method, and the JWT Method, respectively.

The traditional method

The traditional method is typically what is thought of when people mention terminology like cookies and sessions. Briefly, the traditional approach is when users log in to a server, and the server generates two pieces of information: 1.) a long, unidentifiable key and 2.) a record in a database to which that key points. The server gives the authenticated client that key. The key can then be used to fetch user data, authorize requests, etc. It is sent with each request as a cookie. This approach is nice because the server completely controls the authenticated users' information. A downside to this method is that a database lookup is required with each server request. This is both slow and overly complex. It needs to be repeated for every single action the user does. So, every single API call leads to at least two slow DB calls, which can slow down the overall response time and lead to infrastructure overhead. It also leads to security flaws like cross-site-request-forgery.

The JWT method

The JSON-Web-Token (JWT) method was developed to mitigate the aforementioned problem of managing and looking up user information in a database for each call. Briefly, the idea behind JWT is to store the user’s info in the session token itself. The information is digitally signed with a secret string, such that if the client tampers with the payload (say impersonates a different user), the signature will be different and won’t be authenticated. This method is great as it completely eliminates the database lookup. However, now the user information, while signed, can be inspected by anyone. This introduces obvious security flaws. Further, there is no easy way to revoke a token once it's been given. As such, if we wish to restrict a client's access before its token's expiry date, there is no clear way to do this.

The Proposal

What Method Does PEPhub use?

Currently, I believe PEPhub is doing a bit of both. The current authentication implementation is using JWTs, but it is sending them with each request as a cookie. I believe this current method is not in the spirit of modularity or JAMstack, and it has two downfalls. First, sending cookies across origins can pose a challenge. Second, it goes against the current "microservice" architecture. That is, cookies are not congruent with the JAMstack mentality and don't fit in with the model of having multiple software units that can communicate with one another since they are intended to live only within the same origin.

My Proposal

If you do a quick google search you will find endless discussions and debate around session-cookies and JWTs to log users in. I propose that we move away entirely from cookies and have pephub simply mint JWTs to be used to authenticate requests. Specifically, I propose that the PEPhub user interface and any subsequent clients who wish to use PEPhub in an authenticated manner should do so in three steps: 1.) request login to GitHub through PEPhub, 2.) be issued a JWT with a specific expiry date, and 3.) utilize this JWT to authenticate and authorize requests through HTTP headers namely:

Authorization: 'Bearer {JWT}'

Addressing Downfalls of JWTs

As I mentioned, JWTs do have some pitfalls; I can think of three. But, I believe that each pitfall is either 1.) not an issue within the scope PEPhub or 2.) something that can be addressed in the future if need be.

1. Logout doesn’t really log you out: Simply deleting a JWT doesn't remove the "session". If someone gained access to that JWT after you "logged out", they could make requests on your behalf.
2. Revoking a token cannot be done: I don't see any immediate reasons why we would need to revoke tokens. Further, implementing a simple local cache with "black-listed" tokens could be simple enough if the need arises.
3. JWTs are not encrypted: Currently, the PEPhub JWTs are also not encrypted, so we've already agreed this is okay. But even further, there remains no real sensitive data inside the JWT other than the user's basic GitHub information.

Conclusion

In conclusion, I think that we should change two things about the current implementation: 1.) Stop storing JWT's as cookies in the browser, 2.) Authorize requests with an Authorization: Bearer 'JWT' header. This new implementation will make integration with PEPhub and its authentication capabilities much easier down the road.