Search
Online Courses
Pocket Guides
Last Update: 12.01.2018. By Jens in API Series | APIs | Newsletter
It is time for thinking about the securing our API. Right now, it is open to everyone, which we don’t want. So, what choices do we have?
I covered the first three in Spirng Boot and Single-Page-Applications with an additional one of stateful auth session. I wrote an article about using Spring Session before. Check them out for implementation details.
What will we use for the Kanban API?
Basic auth could work because we trust the clients, it’s ours. It could also work if it is an internal application. However, basic auth has always the disadvantage that it is basically sending the username and password to the server in a simple encoded fashion. We should only ever do that over https.
The token variant usually starts with a basic auth or form-based login. On successful login, we will receive a token, and all upcoming requests only send the token along. Usually in an HTTP header. Does also work in our case.
The classic form-based login could work too even when we use an SPA. We could put the SPA behind a Spring Security login and share the session between UI and API. Now we would have two Spring Boot application and when using Spring Session also a shared DB or Redis…
Oauth2 has a particular use case for allowing third-party applications access to our API on behalf of our user. It also includes the concept of an authorization and resource server. The latter is our API, and the authorization server allows access, so we would need to run an instance. Honestly, it got pretty straightforward with Spring Security nowadays to run that, but implementation speed is not everything.
What would you do now if you had to develop the Kanban API for me? Imagine I am your client, how would you advise me?