I created an API Gateway to allow a certain client to access specific routes in my app engine. The client prefers to authenticate using Pre-Shared Key (PSK) over TLS. Is it possible to do that in a Google API gateway?
With the GCP API gateway, you have a limited number of built-in authentication methods. I don’t think we can authenticate using Pre-Shared Key (PSK) over TLS. In order to authenticate using the GCP API Gateway you have to use one of the alternate authentication methods provided in the documentation.If you think it is valid request for GCP API gateway you may raise a Feature request at issue tracker
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.
I have an API that doesn't have an authentication (intentionally). How can I secure it so only my application can make requests and API can identify those API requests coming from that server only?
Well, you need authentication 🤷
In order to verify who is calling your API you need to authenticate them. This doesn't mean that you have to authenticate users. Applications can also authenticate and present their identity to other applications. This is what you need here. You can achieve such app-to-app authentication in a few different ways:
Basic authentication. You can save an ID and a secret in your application and use them to send the Authentication header.
Use OAuth's client credentials flow. This is an OAuth flow that is made specifically for apps to identify themselves to other apps.
Use mutual TLS. You can tell your API what certificate will your application use and accept only connections with that certificate.
Identify with JWT Assertions. In this approach, your application signs a JWT with its ID and the API is able to verify the signature of the JWT.
I am sending a JWT token in api header. I designed this to pass through GCP api gateway and hit cloudrun service. But when passing through api gateway, the whole JWT token changes every time. There is no effect when I call the cloudrun directly without an api gateway. Any ideas about this?
You have several use cases
If you consider that your Cloud Run requires an authentication, but the access to API Gateway doesn't, the API Gateway is able to generate an identity token, based on the service account in its configuration, and add it to the request forwarded to Cloud Run
If you consider that your Cloud Run requires an authentication and you want to use API Gateway as authentication proxy (for instance, all the users that request the API gateway must be authorized by API gateway (by API key, by FirebaseAuth, by JWT token,...), but the users aren't directly granted on the Cloud RUn service, API Gateway is able to generate an identity token, based on the service account in its configuration, and add it to the request forwarded to Cloud Run
If you consider that your Cloud Run requires an authentication and API Gateway is simply a passthrough to centralise the APIs definition, you can set in your x-google-backend definition, the parameter disable_auth to true. That time, API Gateway won't generate an identity token and won't add it in the forwarded request. The identity token received in entry is forwarded to Cloud RUn (it must be a valid token for Cloud Run)
Note: when API Gateway generate an identity token, the initial authorization token is forwarded in a new header: X-Apigateway-Api-Userinfo
Clients that communicate against a single point of entry via an API Gateway over HTTPS against a RESTful API
API Gateway: API Keys for tracking and analytics, oAuth for API platform authentication
User Micro service provides user authentication and authorization, generates JWT that is signed and encrypted (JWS,JWE)
Other micro services determine permissions based on claims inside JWT
Micro services communicate internally via PUB/SUB using JWT in the message and other info. Each micro service could be scaled out with multiple instances (cluster with a load balancer).
Question: Can I cluster the the API Gateway and have the load balancer in front of it. What do I need to consider with respect to managing authentication? ie: sharing of API Keys across the API Gateway cluster?
Extra notes, I'm planning on terminating SSL at the gateway and the use of bcrypt for passwords in the db.
Any feedback would be great, thank you.
Can I cluster the the API Gateway and have the load balancer in front
of it.
Yes, you can. Most of the good Api Gateway solutions will provide the ability to do clustering. e.g. https://getkong.org/docs/0.9.x/clustering/ or you can use cloud based Api Gateway: Azure API Management or AWS API Gateway
What do I need to consider with respect to managing authentication?
These specifics depends on your selection of API Gateway solution.
We're building a public API and clients using this API will need to authenticate, and we proposed to expose an OAuth2 API for this purpose.
However, we also have a need for authentication to be federated, so we see clients talking OAuth 2 with our API, and our API talking OAuth1/2 or SAML2 to the identity provider in the background.
The full flow being:
Client talks OAuth2 to our API.
At the start of this flow, our API redirects the client to a "Choose Your Federated Provider" HTML page.
On choosing a provider, our API talks OAauth1/2 with the provider, passing any redirects back to the client, so the user can provide login details.
Our API exchanges the access code for a access token and refresh token (API keeps these private, and uses them even if the client is off-line).
Our API generates an access code and passes this to the client.
Client exchanges the access code for access token.
The provider supplied access token/refresh token is use by the API in the background, for example to keep a Google calendar up to date, and not passed to the client.
I've not found any examples of this being done with an API. So, what is the established model for providing federated authentication for an API service?
Check out some of the info that Ping Identity provides on their OAuth Essentials page. Specifically, there is a White Paper entitled, "A Standards-based Mobile App IdM Architecture White Paper" (free w/Registration) that you should look at that talks about how you would use SAML + OAuth to secure Native Mobile Apps that require Federation. [Note: I do work for Ping]. It lays out the info flows and token exchanges that need to happen to solve this use case as well as other OAuth related cases.
HTH - Ian