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.


  • 1
    There's not enough information about the system to tell which security system suite best in your specific scenario.
    – Laiv
    Commented Apr 30, 2017 at 18:49
  • What would you want to know? I hope i can give all the information you want.
    – Fjarlaegur
    Commented May 1, 2017 at 5:14
  • You have introduced your knowledge and technologies, but you didn't described the system. Neither the security requirements or goals to achive.
    – Laiv
    Commented May 1, 2017 at 8:14
  • I made some edits. I hope i explained it well now.
    – Fjarlaegur
    Commented May 1, 2017 at 8:24

2 Answers 2


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.

  • I am no expert on authentication systems. Also by "complete own developed system" i mean that i also develop the client (web application). I wont expose any API's (yet) to the public so people can build their own clients. But as you are suggesting, i should use social logins? I don't prefer that way, because i would like to have everything in our own management. But i get that it may be better security wise. So i better use a social login instead of having my own authorization/authentication service? Thanks!
    – Fjarlaegur
    Commented May 1, 2017 at 10:28
  • As I said, OpenID/OAuth2 has nothing “social” in them; there are other providers than Facebook and Google that you could use. The choice between using a third-party and developing an in-house solution is up to you. Commented May 1, 2017 at 10:41
  • Ok i should call them external auth services. Nothing social about them, they are one of the options to provide auth services, got it. But what if i prefer to develop an in house solution? (I am open to any arguments not to of course). Would OAuth2 suffice for an microservice architecture as described?
    – Fjarlaegur
    Commented May 1, 2017 at 10:48
  • THanks. I am not planning on reinventing the wheel. It is way more secure to use existing solutions, i know that. Thanks for all the help, i will look into your suggestions!
    – Fjarlaegur
    Commented May 1, 2017 at 11:45
  • 1
    Then you have to implement your own Authentication server, Authorization server and implement Oauth2 protocol form scratch. Oauth2 is just a protocol. You can combine Oauth2 with JWT (which is a token format. Self-contained web token). What Arseni is suggesting is to get focus on the app business and delegate to already implemented solutions do the rest. There're OAuth providers such as AuthO that may interest you. Or you could deploy a SSO like CAS which has support for Oauth2 , OpenID and authentication. The thing is don't reinvent the wheel. Overall in security.
    – Laiv
    Commented May 1, 2017 at 11:48

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.

  • This would mean each REST API microservice would have to authenticate the user, right? I want the user to be authenticated once and be authorized to call different REST API's. And the REST API's verify if the user is authorized. This doensn't sound as a SSO option. Or am i totally wrong now?
    – Fjarlaegur
    Commented May 2, 2017 at 6:25
  • Rest resources are 'stateless'. So yes auth happens on every request.. but the client caches the crefentials, the user is only asked once. And on the server you use caching to speed up the auth process.basic auth is how its done in your situation.
    – Richard
    Commented May 2, 2017 at 7:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.