Micro services REST with Javascript user authentication/authorization

Question

I am fairly new to the microservice architecture. I am trying to build a web application in this kind of way. After some research online about microservices and having experience with Spring and Angular I want to build a web application with a separate front-end and multiple (separate) back-end REST API's.

How i want to design my application is a javascript/html/css front end (developed by me, no external clients). The front end will communicate via an API gateway (Reverse proxy) to my backend REST API's. The REST API's will be different microservices. I want the user to sign in once (SSO) to be authenticated and authorized for the REST API's. Some API's will be public, but some must be protected. Also this could be on different levels (admin and user API's).

Front end -> API Gateway --> Authorization server
                         |-> User REST API (User and Admin)
                         |-> Statistics REST API (User and Admin)
                         |-> Admin user overview REST API (Admin only)

The thing that worries me is the user authentication/authorization. (Its a big deal in my app). This is where i got lost. I did some research online for this and there are a lot of people recommending Oauth2 for this. Altough i tought Oaut2 is for application to application authorization there seems to be a authorization flow for javascript based web apps (The implicit flow). I want the user to log in in the front end, no social authentication or anything. Complete own developed system.

It is actually language agnostic (Almost each language can implement OAuth2). I am ooking for the best way to implement security authentication and authorization. But i was wondering is OAuth2 is the right thing for this architecture. Is the Oauth2 implicit flow good enough for my own developed front end? Or could/should i use the password flow?

If Oauth is not suitable for this goal, what should be used then? I read about JWT but i am not sure if that is what i need. And if Oauth2 is suitable for my situation, should i use the Implicit or Password flow?

I hope you guys can help me decide and explain things a bit.

Thanks!

Answer 1

I want the user to log in in the front end, no social authentication or anything.

There is nothing social in OpenID/OAuth2. Basically, the benefit of OpenID and OAuth2 is for the developer to rely on an external system to handle all the authentication in the first case, and authorization in the second case.

For the developer, this means that:

• The developer doesn't take the risk of introducing bugs which would, ultimately, allow a hacker to gain access to the system as a different user, or tamper with user's credentials.

• The system doesn't store any hashed passwords, which makes the system much less interesting to hack for someone who wants to get users' passwords.

• The developer add extra providers with ease.

• When a provider starts supporting an additional security feature, such as Two Factor Authentication, you get it for free.

For the user, this means that:

• There is one password less to remember if the user is already registered on the third-party website which provides OpenID/OAuth2 service.

• Or, there is one more account to create if the user is not registered on the third-party website. This could be an issue when the user doesn't want to register on that third-party website. For instance, if you make it mandatory to have a Facebook account to use your product, I won't be among your customers.

• The overall user experience becomes slightly poorer, due to multiple redirects, as well as the loss of context (“Why am I redirected to Facebook? Is this a error?”)

The actual OpenID and OAuth2 provider could be anything: while it is true that many social websites also do let you use their OpenID/OAuth2, they are not alone. Non-social providers include SalesForce, PayPal and Amazon.

Complete own developed system.

Why would you do that?

As explained above, the benefit of OpenID/OAuth2 is to mitigate the risk by moving complex code and sensitive data out of your servers. Let experts from Amazon or Google handle this thing. Don't put yourself and your users at risk. Unless, of course, you are the expert and you've worked for the last decade on authentication systems, in which case, go for it.

But i was wondering is OAuth2 is the right thing for this architecture. Is the Oauth2 implicit flow good enough for my own developed front end? Or could/should i use the password flow?

OpenID is the password flow. Open Developer's Tools panel in your browser and track the network stream; you'll see there is no magic there. For your web application, it will be pretty straightforward to set up OpenID or OAuth2, depending on the maturity of thir-party libraries which are available for your language of choice.

However, when it comes to accessing the APIs from the client, you'll have problems either way: at some moment, the web application would need to tell the API that a specific user with a specific key and secret will need to access it.

Basically, at some point, either the app or the API will need to generate a key-secret pair which will then be used by the browser when doing AJAX requests to that API. The app would also need to tell the API that a given key is associated with a given user: this way, the user will be able to access her data, but not the data of somebody else.

This mechanism is independent of the choice between OpenID/OAuth2 and a home-made system. The scope of authentication is the web application; APIs don't authenticate users; they authenticate other applications, would it be your own web app, or a third-party.

Answer 2

Rest is about leveraging the already existing mechanisms of the internet. The web already gives you several http authentication mechanisms.BASIC, Digest etc. Consider using basic auth over ssl.