I'm developing an authentication/authorization system in Node Js for a microservice based application.
I read some articles and documentation about the OAuth2 standard but I need some clarification for my use case.
Basically OAuth2 has some actors like:
Resource owner (user)
Client app (a web application in some OAuth2 grant flows like authorization code, implicit, password)
Authorization server
Resource server (service I want to access to)
So in my database I store a client (web application) with its client_id and client_secret.
Let's suppose that one of my microservice needs to access data from another microservice. Both of them espose a REST Api.
There is no interaction with user, all is done in the background. In this case I would use the client credential flow.
Following OAuth2 rules, both of them are resource servers but in the same time it looks like they are client apps as well.
So should I register them in the client DB table/collection with client id, secret etcetera or did I make some mistakes?
Thank you
If I understood your question correctly, the caller micro-service is your client and the one that is being called is your resource. A lot depends on what type of micro-service communication pattern have you implemented. If you are implementing an "API Gateway" pattern, then your Gateway is always client and all other micro-services can be treated as resources. But if your micro-services can call each other then like you mentioned each one of them have to be registered as client and resource at the same time.
Related
I am working on microservices application where the client application sends the access token to orders microservice with the POST call. When saving the order, the inventory micro-service should be called to update the inventory. The Inventory microservice updateIntentory method should also be protected.
In this use case, should I be propagate the same access token to the inventory microservice and restrict the api access to update inventory or should I make use of client-credentials grant flow to allow saveOrder method in the order microservice to invoke the updateInventory method in the inventory microservice.
Note: Both the order and inventory microservices are acting as resource servers.
What is the right approach.
Good question:
BOUNDARIES
If you were calling an external API belonging to someone else you would definitely use client credentials to get a token that entitles you to call that API.
MICROSERVICES
If the data owner is the same then you should simply forward the access token. This is how OAuth is meant to work: a scalable architecture that only requires simple code:
Client gets an access token with scopes for multiple APIs
Each API validates the JWT
Each API verifies its own scopes
Each API trusts the claims in the JWT and uses them for authorization
The Scope Best Practices article explains this for a real world system.
HIGH PRIVILEGE OPERATIONS
It is common to get a fresh token for high security operations, such as redirecting the user with a payment scope. This should be the exception rather than the rule though.
I've been looking into developing a microservice architecture using SpringBoot and some netflix libraries such as Eureka, Zuul, Ribbon; however, I appear to be hung up with the security design.
My goal is to use a third party web based service such as Okta.com to manage all my users and applications. Okta uses Oauth2 which I believe would make my application stateful. My goal is to keep my application stateless for load balancing purposes.
I would be using the following service module architecture,
Gateway Service
Auth Service (Authenticate against Okta)
Microservice 1 (role_admin, role_sales)
Microservice 2 (role_admin, role_employee)
My understanding is when the gateway has requested routing to Microservice 1 or Microservice 2, a token would need to be forwarded along with the request and if no token is present, a request to the Auth Service at the gateway would need to be made in order to obtain a token from Okta using Oauth2.
My next piece of understanding is while using oauth2, when the token is present and has been forwarded along to Microservice 1 or Microservice 2, the token would need to validated against okta again. The groups would be contained within the token.
My question is could Okta be used solely for the purpose of Authenticating and Authorization, but rather than passing around the stateful oauth2 tokens generated by Okta, create a stateless JWT which would contain roles and user info and pass that back to the microservices?
I'm just wondering how to use a service like Okta in a microservice architecture, but still keep my microservices stateless and I'm not sure my thought process is correct.
I'm creating an online store REST API that will mainly be used by a mobile app. The plan is for a microservices architecture using the Spring Cloud framework and Spring Cloud OAuth for security.
My question is really on best practices for communication between microservices: Should I have each service register for their own token, or should they just pass the user's token around?
For example, I have 3 services: user-service, account-service, order-service.
I've been able to implement two procedures for creating an order: One passes the user's token around, and in the other each service gets their own token. I use Feign for both approaches.
So for option 1: order-service -> GET account-service/account/current
order-service calls the account-service which returns the account based on a userId in the token. Then the order-service creates an order for the account.
Or for option 2: order-service -> GET account-service/account/user-id/{userId}
order-service gets the userId from the sent token, calls the account-service with it's own token, then creates the order with the retrieved account.
I'm really not sure which option is best to use. One better separates information but then requires two Feign Clients. However the other doesn't require the 2 clients and it becomes easier to block off end certain endpoints to outside clients, however it requires extra endpoints to be created and almost every service to go digging into the Authentication object.
What are all your thoughts? Has anyone implemented their system in one way or another way entirely? Or perhaps I've got the completely wrong idea.
Any help is appreciated.
I have found below 3 options:
If each microservice is verifying the token then we can pass the same token. But the problem is - in between same token can be expired.
If we use client_credentials grant then there we are having two issues: one is, we need to send the username/id in next microservice. Another one is, we need to request two times - first for getting the access token, next for actual call.
If we do the token verification in API gateway only (not in microservices) then from the API gateway we need to send the username in every microservices. And microservices implementation needs to be changed to accept that param/header.
When you do server to server communication, you're not really acting on behalf of a user, but you're acting on behalf of the server itself. For that client credentials are used.
Using curl for exemple :
curl acme:acmesecret#localhost:9999/oauth/token -d grant_type=client_credentials
You should do the same with your http client and you will get the access token. use it to call other services.
You should use client tokens using the client_credentials flow for interservice communication. This flow is exposed by default on the /oauth/token endpoint in spring security oauth.
In addition to this, you could use private apis that are not exposed to the internet and are secured with a role that can only be given to oauth clients. This way, you can expose privileged apis that are maybe less restrictive and have less validation since you control the data passed to it.
In your example, you could expose an public endpoint GET account-service/account/current (no harm in getting information about yourself) and a private api GET account-service/internal/account/user-id/{userId} that could be used exclusively by oauth clients to query any existing user.
We are developing an application in a microservice architecture, which implements signle sign-on using Spring Cloud OAuth2 on multiple OAuth2 providers like Google and Facebook. We are also developing our own authorization server, and will be integrated on next release.
Now, on our microservices, which are resource servers, I would like to know how to handle multiple token-info-uri or user-info-uri to multiple authorization servers (e.g. for Facebook or Google).
This type of situation is generally solved by having a middle-man; a single entity that your resource servers trust and that can be used to normalize any possible differences that surface from the fact that users may authenticate with distinct providers. This is sometimes referred to as a federation provider.
Auth0 is a good example on this kind of implementation. Disclosure: I'm an Auth0 engineer.
Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation.
(emphasis is mine)
It's not that your resource servers can't technically trust more than one authorization server, it's just that moving that logic out of the individual resource servers into a central location will make it more manageable and decoupled.
Also have in mind that authentication and authorization are different things although we are used to seeing them together. If you're going to implement your own authorization server, you should make that the central point that can:
handle multiple types of authentication providers
provide a normalized view of the user profile to downstream resource servers
provide the access tokens that can be used by your client application to make authorized requests to your microservices
I am learning oAuth2 for the first time. I am going to use it to provide authentication for some simple web services using a two-legged approach.
According to what I have read, the flow should go like this: the web service client supplies some kind of credential to the oAuth server (I'm thinking of using JWT). If the credentials are valid, the oAuth server returns an access token. The web service client then supplies the access token when attempting to use the web service end point.
Here is my question, why not just supply the JWT when making a request to the end point? Why is oAuth's flow conceived this way. Why not just supply to JTW to the end point and use that for authentication? What is the advantage of having the extra step of getting an access token?
Thanks!
You can certainly supply the JWT directly to the web service. The questions is how do you generate it in a way that the service trusts.
A JWT is and access_token, but not all access_tokens are JWTs.
Your client can issue a JWT, sign it with a key (or a cert) and then send it to the API. The advantage of having a 3rd party (an Issuer) is that you can separate authentication from issuing tokens. Clients can authenticate in multiple ways (e.g. usr/pwd, certs, keys, whatever) and then use the JWT to call your API.
The additional abstraction gives you more flexibility and management scalability. For example: if you have 1 consumer of your API, then you are probably ok with a single credential (or JWT, or whatever). If you plan your APIs to be consumed by many clients, then handing that responsibility to a specialized component (e.g. the the issuer) makes more sense.
OAuth BTW, was designed for a specific use case: delegate access to an API to another system on your behalf. You grant access to system-A to access resources on system-B on your behalf with a permission scope.