I'm reading a tutorial provided by AWS explaining how to break up a monolithic NodeJS application into a microservice architectured one.
Here is a link to it.
One important piece is missing from the simple application example they've provided and that is user authentication.
My question is, where does authentication fit into all this?
How do you allow users to authenticate to all these services separately?
I am specifically looking for an answer that does not involve AWS Cogntio. I would like to have my own service perform user authentication/management.
First, there is more than one approach for this common problem.
Here is one popular take:
Divide your world to authentication (you are who you say you are) and authorization (you are permitted to do this action).
As a policy, every service decides on authorization by itself. Leave the authentication to a single point in the system - the authentication gateway - usually combined inside the API gateway.
This gateway forwards requests from clients to the services, after authenticating, with a trusted payload stating that the requester is indeed who they say they are. Its then up to the service to decide whether the request is allowed.
An implementation can be done using several methods. A JWT is one such method.
The authenticator creates a JWT after receiving correct credentials, and the client uses this JWT in every request to each service.
If you want to write your own auth, it can be a service like the others. Part of it would be a small client middleware that you run at all other service endpoints which require protection (golang example for middleware).
An alternative to a middleware is to run a dedicated API Gateway that queries the auth service before relaying the requests to the actual services. AWS also has a solution for those and you can write custom authentication handlers that will call your own auth service.
It is important to centralize the authentication, even for a microservices approach for a single product. So I'm assuming you will be looking at having an Identity Service(Authentication Service) which will handle the authentication and issue a token. The other microservices will be acting as the service providers which will validate the token issued.
Note: In standards like OpenID connect, the id_token issued is in the format of JWT which is also stateless and self-contained with singed information about the user. So individual Microservices doesn't have to communicate with the authentication service for each token validation. However, you can look at implementing or using Refresh tokens to renew tokens without requiring users to login again.
Depending on the technology you choose, it will change the nature how you issue the tokens and validate.
e.g:
ExpressJS framework for backend - You can verify the tokens and routes in a Node Middleware Handler using Passport.
If you use API Gateway in front of your Microservice endpoints you can use a Custom Authorizer Lambda to verify the tokens.
However, it is recommended to use a standard protocol like OpenID connect so that you can be compatible with Identity Federation, SSO behaviors in future.
Since you have mentioned that you are hoping to have your own solution, it will come also with some challenges to address,
Password Policies
Supporting standards (OpenID Connect)
Security (Encryption at rest and transit especially for PIDs)
SSO, MFA & Federation support etc.
IDS/IPS
In addition to non-functional requirements like scalability, reliability, performance. Although these requirements might not arise in the beginning, I have seen many come down the line, when products get matured, especially for compliance.
That's why most people encourage to use an identity server or service like Cognito, Auth0 & etc to get a better ROI.
Related
I would like to use mTLS to protect microservices instead of Open ID Connect.
As I understand how mTLS works, it encrypts the communications between two services via SSL handshake.
However, can I use mTLS as authentication mechanism instead protect services through Open ID Connect?
You can use mTLS as an infrastructure security solution between microservices, but it will have limitations, and will not be able to manage user level security. So it depends who the clients of your microservices are, and how you need to authorize API requests.
USER LEVEL SECURITY
This is where OAuth and OIDC are used, and often there is a web or mobile app as a client:
The client runs a code flow and gets tokens
The client sends an access token to microservices
Microservices receive a JWT access token that identifies the user
Microservices can forward this to other microservices when required
Because of the user identity in the access token, the API can perform user level authorization, eg to. ensure that a user can only view their own purchase history.
COMBINING mTLS AND OAUTH
It is common to combine these two building blocks, and security standards / regulations sometimes require this. See this financial-grade security overview for some example scenarios.
I see different opinions among software engineers regarding where to place authentication in a Microservice architecture.
Many support the idea that authentication should be placed at the API gateway level and only the Authorization at Microservice level.
For authentication I mean checking a JWT that was issued after authentication with credentials, for example...
Now, if the API gateway is the only entry point of our backend then it is reasonable to have it in the Frontline when it comes to authenticate the requests.
The problem is that the API gateway, being a proxy, shouldn't really be bound to the underlying services, right?
Let's say that some of the endpoints require authentication and some of them are publicly accessible. I feel that in this case it's better to have it at the Microservice, since the Microservice knows all the details of the API that it exposes.
Otherwise the API gateway should ask the Microservice if the endpoint is public or not or get this information from a database.
But wouldn't be too much of overhead to perform this request to the service/database everytime the gateway is hit?
Furthermore, depending on the framework we use to implement the security layer we might not have the chance to check the accessibility of an endpoint at runtime. So, whenever we make an endpoint public we should redeploy the gateway to get the new information about what requires authentication and what not.
What are your suggestions regarding this topic?
Looking at it strictly from a security perspective.
From what I have seen with microservice architectures, the gateway only performs authentication, each micro service / endpoint needs to handle its own authorization checks at a bare minimum.
So for your public URLs, the gateway would not perform any authentication checks.
For your private/secured endpoints, the gateway will perform authentication checks and authorization checks at a microservice level, but you will still need to handle the business rules to be followed.
Example:
/public/article1 - does not need any authentication or authorization checks
/private/newsletter - requires authentication from gateway, but may not require authorization checks from the microservice
/private/account - should require both authentication + authorization check from gateway as well as from the microservice to make sure you are accessing only your account.
We are in the process of developing a mobile (native) app, and are looking at how we should do user authentication. Most of the information I have found have been about web apps and / or third-party apps accessing public APIs. OAuth 2 is therefore recommended to be used most of the time.
Since we develop the app and our API isn't public, it seems like the Resource Owner Password Credentials OAuth 2 flow could be an option, but according to oauth.net that is not recommended any more.
We are using Google App Engine (with Node.js) and Cloud Endpoints (Not sure if end-points would be needed since it's a private API, but that is another question) as the back-end, and both Firebase Auth and Auth0 has built in support in Endpoints. However, we have some special requirements that doesn't make those services suitable (Swedish BankID for example).
What other options are there when authenticating users? Could we write an app in App Engine to check the users credentials against our database, and then send back a JWT (Cloud Endpoints supports custom authentication methods as long as they use JWT)? Would it be safe to do this ourselves? I have found some Node.js libraries for authentication, but most seem to be aimed at web apps. Are there any that are suited for a native app front end?
For authentication, yes, you can perform the check yourselves, in your database and deliver or not a JWT according with the authentication result.
However, and it's obvious, this authentication service must be public (because it's for authenticated unauthenticated users!). And thus, you can be expose to attacks on this service. And because it's the authentication service, if the service goes down, no one can no longer sign in, or worse, if you have a security breach, your user database can be stolen.
That's why, to use existing services, with all the protections, all the resources (people, monitoring, automatic response, high availability,...) deployed to managed a large number of threats. Firebase auth, Auth0, Okta (...) are suitable providers but I don't know your Swedish requirement and you might not avoid specific developments
I developed my Heroku app that exposes APIs only (no UI) and it works fine.
But how can I restrict the APIs to certain authorized/authenticated users only?
I absolutely need an authentication layer to protect the app APIs and prevent unauthorized accesses. A sort of login(user, psw) call to use before an external system can start invoking my API.
But I don't find any reference in the docs, it only says that these are the main security best practices:
Heroku SSL
Force the use of HTTPS
Trusted IP Range
Any idea?
That's something you'll need to implement at the application layer and not something that Heroku provides. At it's simplest you could implement basic auth in your app so that the user would pass them with their request, a more complex solution would involve user accounts and oauth etc etc.
You could implement all the authentication logic directly in your app.
Alternatively, take a look Auth0, which basically provides you with authentication and identity management as a service. You can easily add Auth0 to your Heroku app as a free add-on via the Heroku Elements marketplace.
They have lots of different use-cases and associated walk-throughs, and they offer a very generous free-tier.
From your requirements, it sounds like you might want to look at Auth0 Machine to Machine applications, using the OAuth2 Client Credentials Grant. With that, your external system(s) would basically need to authenticate with Auth0 using a Client Id and Client Secret (that you could generate in Auth0 and supply to them). Then, they would access your API with a JWT that you could easily validate in your app (Auth0 will provide you with generated code in many different languages for you to do that very easily). Your API will then reject requests without a valid JWT (by sending a "401 Unauthorized" response).
This may all sound a little intimidating at first, but it's really worth going through the relevant Auth0 "quickstart". They really go out of their way to try to make it as easy as possible!
I'm trying to design a green-field project that will have several services (serving data) and web-applications (serving HTML). I've read about microservices and they look like good fit.
The problem I still have is how to implement SSO. I want the user to authenticate once and have access to all the different services and applications.
I can think of several approaches:
Add Identity service and application. Any service that has protected resources will talk to the Identity service to make sure the credentials it has are valid. If they are not it will redirect the user for authentication.
Use a web-standard such as OpenID and have each service handle it own identities. This means the user will have to authorize individually each service/application but after that it will be SSO.
I'll be happy to hear other ideas. If a specific PaaS (such as Heroku) has a proprietary solution that would also be acceptable.
While implementing a microservice architecture at my previous job we decided the best approach was in alignment with #1, Add identity service and authorize service access through it. In our case this was done with tokens. If a request came with an authorization token then we could verify that token with the identity service if it was the first call in the user's session with the service. Once the token had been validated then it was saved in the session so subsequent calls in the user's session did not have to make the additional call. You can also create a scheduled job if tokens need to be refreshed in that session.
In this situation we were authenticating with an OAuth 2.0 endpoint and the token was added to the HTTP header for calls to our domain. All of the services were routed from that domain so we could get the token from the HTTP header. Since we were all part of the same application ecosystem, the initial OAuth 2.0 authorization would list the application services that the user would be giving permission to for their account.
An addition to this approach was that the identity service would provide the proxy client library which would be added to the HTTP request filter chain and handle the authorization process to the service. The service would be configured to consume the proxy client library from the identity service. Since we were using Dropwizard this proxy would become a Dropwizard Module bootstrapping the filter into the running service process. This allowed for updates to the identity service that also had a complimentary client side update to be easily consumed by dependent services as long as the interface did not change significantly.
Our deployment architecture was spread across AWS Virtual Private Cloud (VPC) and our own company's data centers. The OAuth 2.0 authentication service was located in the company's data center while all of our application services were deployed to AWS VPC.
I hope the approach we took is helpful to your decision. Let me know if you have any other questions.
Chris Sterling explained standard authentication practice above and it makes absolute sense. I just want to put another thought here for some practical reasons.
We implemented authentication services and multiple other micro services relying on auth server in order to authorize resources. At some point we ran in to performance issues due to too many round trips to authentication server, we also had scalability issues for auth server as number of micro services increased. We changed the architecture little bit to avoid too many round trips.
Auth server will be contacted only once with credentials and it will generate the token based on a private key. Corresponding public key will be installed in each client (micro service server) which will be able to validate the authentication key with out contacting auth server. Key contain time generated and a client utility installed in micro service will validity as well. Even though it was not standard implementation we have pretty good success with this model especially when all the micro services are internally hosted.