Last Update: 23.01.2018. By Jens in API Series | APIs | Newsletter
Last time we started talking about security and I asked you how you would advise me as your client.
The right answer, of course, was to ask me more questions about the goal of the Kanban API. So, here we go.
The initial goal was to build a simple Kanban API as a set of exercises. We accomplished the first version. To secure it, basic auth with a single user would be enough. Even for the next steps, basic auth will work just fine.
My original plan was to extend the first version with multiple kanban boards and users, covering authN and authZ, background process and maybe even payment integration (a gray area as a UI is involved). This will also work with basic auth. However, Spring Session would be a better fit as it supports auth via a token. So, the user had to log in at one endpoint, e.g., using basic auth and receives a token in return. All subsequent requests are made with the token. The client will be a single-page application running in the browser and definitely distribute outside of the API and static, so a Tomcat session is not a good fit.
Oauth2 does work in this context too but mainly will be useful if we had more than one client and other clients are not developed by us. It is also too complex for emails and so not a good fit for the API series.
So, with this assumptions, we move forward using Spring Session with login in the API and a token for all other requests.