I'm in the progress of implementing a microservices architecture with a single entry endpoint for my clients, a API Gateway. This is my suggested authentication flow:
1). Client (SPA) passes user credentials to the API Gateway, which passes them further to my Authorization/Authentication Services.
2). The Auth Service validates credentials and issues some form of opaque token, which is passed back to the client through the API Gateway.
3). The Client sends the token as a header to each request. The API Gateway exchanges this opaque token to a JWT from the Auth Server and stores it in a cache. The JWT is then attached to all downstreaming requests and my internal microservices validates the JWT (Issuer, Audience).
I'm in doubt if any OAuth/OpenID protocols supports this out of the box or if I would have to implement this my self. (Not desirable!).
Would it be a better solution if the Authentication Service was located outside of the API Gateway?
Thanks in advance.
Related
I know one of API Gateway offers is to provide a security layer of any backend APIs. But how if the case is the backend has its own authentication already (let say api key, jwt or other)? What is the better approach / best practice:
Modify those backend APIs to become "plain API" (without any auth), so will rely only on API Gateway auth (OAuth2)
Keep the backend auth as it is, but then create a microservice that will act as wrapper API to handle that backend auth.
The goal is to prevent double authentication & give the same experience to the clients where they only need to pass 1 authentication which is by the API Gateway. Thank you!
I would keep the backend's API security. There is nothing wrong with having secured communication behind an API gateway. As a matter of fact, I recall this being a recommended approach.
To prevent double authentication, would it be a suggestion to define a public (unsecured) end-point on the API gateway to access the authentication end-point of the authentication server used by your backend services. The client receives the authentication token from that authentication server and the API gateway passes the token through to the API of your backend services.
Another possibility could be to authenticate towards the API gateway but let the API gateway use the same authentication server as your backend services. Some gateways allow you to forward the authentication to an authentication server somewhere outside of the API gateway.
We have a .NET microservice based app where the Gateway is built using Ocelot. Until now we didn't do any authentication in the Gateway, the frontend calls an Authentication Provider service which responds with an JWT token, the token gets added to request headers and then, the new requests go through gateway and each particular microservice is concerned with authentication and authorization.
We also have API Key based authentication in place, but it's not used until now.
I added a new microservice with authentication done by API Key and I want to handle authorization in the Gateway. That means the gateway should check the claims based on JWT token and if claims matches forward the request to the microservice using an API key header.
How can I do it with Ocelot, instead of writing controllers and actions for each corresponding microservice controllers and actions? I thought about implementing Delegating Handlers to take care of it, but maybe there is a better way?
A clean way to do this, is to have the access token between the client and the API gateway and to then use the token exchange flow between the gateway and the underlying APIs so as to keep a potential attack surface on the initial access token small and avoid exposing internal mechanics (e.g. multiple audiences of underlying APIs in your initial access token, multiple api scopes).
There are many sources of information about this online. Here's one to get you started.
I have project with many micro services each one doing its job. One of them responsible for authentication and authorization. But its not clear how other services should check users permissions. Is there any mechanism to deal with this task?
One of the best approaches is the OAuth delegation protocol with JSON token JWT
Authentication in micro-services architecture
the user send his credentials to the OAuth server
The server Checks the user's information (from LDAP server for example), then gives him an access token
the user send his request with the access token to the API Gateway
the API Gateway extracts out the access_token from the request, then he will talks to the Token Exchange endpoint to validate it and then issues a JWT
this JWT That contains all the necessarily information about the user will be sent to the micro-service.
the micro-service also should verify the validity of the token by talking to the token exchange endpoint.
when the token is checked, the micro-service can start its job.
I think this link will be useful for you Securing Microservices
You said that this responsibility belongs to a microservice. So, the other microservices don't check permissions, they delegate.
If you use an API Gateway and the other microservices are not accessible from the outside then it calls the authentication/authorisation microservice before forwarding the request to the upstream microservice.
If you don't use an API Gateway then each microservice call the authentication/authorisation microservice before actually performing the action.
we plan to introduce an API management solution and we're currently setting up a proof of concept with WSO2 AM. We want to use the WSO2 API gateway to check whether a certain consumer application is allowed to use an API and to throttle the request rate.
I work on the identity workflow and I wonder how a consuming application can pass a JWT token to the backend service with WSO2-AM in between.
First, this is our current scenario:
Without API gateway
The consuming application gets a JWT token for its carbon user from an identity provider. The JWT contains some claims about the user, e.g. the roles he/she belongs to.
The app calls the service an passes the JWT token in the Authorization HTTP header like: Authorization: Bearer
The service validates the issuer and signature of the JWT and retrieves the claims from it.
So, this is pretty straight forward. Now we put an API gateway in between the application and the service:
With API gateway
The consuming application gets a JWT token for its carbon user from an identity provider.
The consuming application uses OAuth2 to get an access token for the following API calls. We can use the client_credentials grant type and simply pass the the client id and client secret. I haven't yet tried it, but we could possibly use the JWT grant type (see https://docs.wso2.com/display/ISCONNECTORS/Configuring+JWT+Grant+Type) and use the JWT for passing user information to the API gateway.
The API gateway validates the JWT against the public key of the identity provider when using the JWT grant type.
An access token is returned to the app.
The app sends an API request to the gateway and passes the access token in the Authorization HTTP header.
The gateway validates the access token.
The gateway forwards the API request to the service.
And there is my problem: How can the JWT from 1/2. be passed to the service?
There is a documentation for "Passing Enduser Attributes to the Backend Using JWT" (see https://docs.wso2.com/display/AM210/Passing+Enduser+Attributes+to+the+Backend+Using+JWT), but this would introduce a new JWT, issued and signed by WSO2-AM, and I'm not sure, whether this JWT contains all information from the JWT used to create the access token (or even the original JWT).
Another way I could think of is using a custom HTTP header for passing the JWT through the gateway to the service. I cannot use the Authorization header (as we do without the API gateway), because WSO2-AM expects the access token in that header.
Since I'm not happy with either solutions, I want to ask the experts: How would you solve this?
Thanks,
Torsten
The only possibility I can think of is to send the JWT token in a custom Header for the backend service.
I've some questions regarding authentication in a microservices architecture. I've right now a monolithic application and my goal is to split the application in small microservices.
My bigest problem is for authentication (for now). After reading a LOT a documentation, It seems that the best solution is to use OpenID Connect to authenticate an user to retrieve a JWT that can by passed with the request to the microservices.
Also, to avoid having multiple endpoints, you can deploy and API Gateway to have only one endpoint for the end user. Ok, so now I've two questions with this architecture.
The standard flow for authentication will be :
An user contact my identity server in OpenID Connect with the implicit flow and get the id_token (JWT) and also the access_token. The user can now contact my API with this access_token. The API Gateway will valide the access_token with the identity server and also retrieve the JWT to add it to the sub request to the microservice API.
1/ How the API Gateway can get the JWT from the access_token? From what I red from the documentation (http://openid.net/specs/openid-connect-core-1_0.html), It can contact the "/userinfo" endpoint but It will get just the JSON format not the JWT...
2/ I want to allow authenticated calls between my microservices. So each microservice needs to be able to generate a JWT to contact other microservices directly. My first thought was to contact the identity server. But with the OAuth2 Client Credentials flow, I don't retrieve a id_token or a JWT. Just a classic OAuth2 access token without JWT. My second thought was that the microservice can directly sign its own JWT with a certificate issued by the same PKI as the one used by the identity server. That mean that a JWT can be sign by several certificats but from the same private PKI. When a microservice receives a JWT, It needs to be able to identify witch certificat was used to sign the JWT. I don't find anything on the RFC regarding this problem. I can add my own private claim in the token to have the certificate but after several days of browsing the web without seeing this kind of solution, I'm wondering if I'm not on the wrong path... To sum up, how can i perfom "User to service" authentication AND alors "service to service" authentication in JWT?
Thank you very much!
I am implementing a similar solution. Not sure if it will address to your question completely, but, I hope it helps:
You can implement a new authentication micro-service to convert your oAuth2 access token to JWT token. This microservice will also sign this JWT token.
Your API gateway will route all client requests to authentication service, which will validate this token from IDM and will convert it to a signed JWT token.
API gateway will pass this JWT token to other microservices which will validate the signature from Authentication Service's public key. If the signature validates, roles can be extracted out of it for authorization.
Each microservice can have its own IDM credentials configured and when it wants to call any other microservice, it can generate an access token and call Authentication Service to get JWT which can be passed in call to other microservices.