We are trying to set up a scheduled job based on NodeJS which will call an API via an API gateway. The API calls another API. There is no user or browser involved. The call must be authenticated and have a valid OAuth token from our IdP. How should it look like to have a more secure approach?
How the flow should look like? Which one the API Gateway or the second API should validate the token? or both? Thanks
A key point is that JWT access token validation is designed to scale. In older architectures it was common to use perimeter security (eg API gateway validates token) but this is no longer recommended.
Instead validate the JWT in each API using a library. Here is some example code and for other technologies see Curity API Guides.
Here are a couple of related articles if you are interested in API security trends:
Zero Trust Architecture
Phantom Token Pattern
Finally, this article discusses that JWTs can often be forwarded between microservices, to keep your code simple.
We have a Mulesoft Cloudhub environment which we are planning to deploy public APIs and we also have a VPC configured where we will deploy private APIs.
I'm looking at how best to secure the APIs and seen the following approaches:
Basic Authentication
Client Id and secret
OAuth
LDAP
SAML
My query is when should you use each one? Are their example use cases? E.g. OAuth seems to be more secure than basic authentication and client id and secret so why not use OAuth all the time and forget about the other two?
Thanks
OAuth is geared more towards authorisation rather than just authentication.
For example OAuth 2 has many different flows geared towards different use-cases. Such as 3 legged OAuth allowing you to use an external identity provider allow users to be authorised to access your resources. In a way, you’re not performing any authentication at all.
Http basic can still have a purpose in simple scenarios MAYBE when the cost and/or effort of using something else is not worth it and it’s internal network and the OJ already have some sort of ldap or active directory type thing is use for other apps (and using SSL is very important here as basic auth credentials are plain text)
For client id and secret, although it is similar to username/password, it’s more in the semantics - you are trusting a client rather than a person with the credentials.
For example, you can use client id to authenticate actual clients like a mobile application or a web app. Client id implementation like MuleSoft’s API Manager also allow you to add policies such as rate limiting and SLA based rate limiting so you can limit specific client applications to not overload your API.
You could use it alongside OAuth. Client ID/Secret for accessing the API but OAuth for authorising the end-user .
Here is a more detailed article discussing the pros and cons of the various common api auth mechanisms and a link to choosing between the various OAuth flows for your use-case.
https://nordicapis.com/3-common-methods-api-authentication-explained/
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
I have hosted a web service on App engine cloud endpoint. The APIs are protected by Auth2.0 as google say but for google accounts.
What I want to achieve is allow these APIs to be accessed using 3rd party tokens. Lets say I have my on Authentication server also providing User Management. I want my google endpoint APIs to be access based on the 3rd party token I provide at the time of API call.
Is this possible?
If Yes, Where should I write the mechanism to verify the clients authenticity and hint of how its to be done.
Also is there any demo project available that provides user management and authentication server and returns a token that can be accepted by App Engine.
Yes
On your app engine project, create the authentication mechanism to validate clients.
As such, there is no single solution available for User management, Authentication Server and Token Issuance, but separate modules are easily available.
I'm planning to use oauth for securing api exposed to web only to be used by the applications we create. Is oauth an overkill. Can someone recommend something else if you think it is an overkill. We secure the channel with TLS too.
OAuth is a protocol designed to allow an application to access resources via an API even if the resource owner (user) is not present. That doesn't mean you can't use it when the user is there to provide access to your APIs. It should not be hard to find an implementation for your platform.
Making the API private to your application will work just fine if your application is a web application in which you can keep a secret (the client credentials).
If your application is a JavaScript application accessing the API from the browser (or even a native application), you can't keep secrets in those clients.
You'll have to trust on authenticating your users to access your API.
I am currently developing a web application that is right now comprised of a front end which displays and interacts with the data using a REST API we have written. The only thing that will ever use the API is our front end website, and at some point a mobile app that we will develop.
I have done a lot of reading about how OAuth is the ideal mechanism for securing an API and at this point I am starting to have a good understanding of how it works.
My question is -- since I am never granting access to my API to a third-party client, is OAuth really necessary? Is there any reason it is advantageous? Furthermore, because the back end is simply the API, there is no gateway for a user to authenticate from (like if you were writing an app using the Twitter API, when a user authenticates they would be directed to the Twitter page to grant to access then redirected back to the client).
I am not really sure which direction to go in. It seems like there must be some approach halfway between http authentication and OAuth that would be appropriate for this situation but I'm just not getting it.
From my point of view, one of the scenarios that favor OAuth over other options is to work with untrusted clients, no matter if these are developed by you or a third party.
What's an untrusted client? Think from the point of who handles the credentials that grant access to your API.
For example, your web application could interact with your API in two falvors:
Your web app server side talks to your API. Your web app server is a trusted client because the credentials to access your API can only be access by whom have access to the server...You and your team. You could authenticate your web app server with a client_id and a client_secret.
You may want to make calls directly to your API from your Web app client, which runs on the end user's browser using JavaScript. The end user's browser is an untrusted client. If you were to deliver the credentials to your API down to the browser, anyone could check the JavaScript code and steal your credentials.
A third party Native App is also untrusted. A malicious developer that uses your API could save the credentials of and end user of your platform.
Your Native App is a trusted client and could manage the authentication with a simple username , password and a client id identifying your App.
How can OAuth help? OAuth Authorization code and Implicit grants can help you with this issue. These flows only work with clients that support a redirect, like a browser. And let you authenticate an untrusted client and a user against your Authorization Server to gain access to your Resource Server, your API, without exposing the credentials. Take a look at the RFC to see how it is done.
The good thing of OAuth is that it not only supports these redirect based authentication flows, but it also supports client credentials grant and user credentials grant. So an OAuth Authorization Server would cover all cases.
OAuth 2.0 originally seems like a PITA if you think about having to build a lot of it yourself, but most languages have some really solid OAuth 2.0 setups which you can just bolt in with varying amounts of fiddling. If you're using a framework like Laravel or RoR then it's barely any work.
PHP: http://oauth2.thephpleague.com/
Ruby (Rails or Grape): https://github.com/doorkeeper-gem/doorkeeper
If you don't want to redirect users as suggested in your post then ignore other comments and answers that talk about two legged flows. You can use the client_credentials grant type to have apps just provide their client id and secret in return for an access token, which is nice and easy.
I would ask how private are we talking, because if the only systems talking to it are within the backend and have no interaction with the outside world you could probably leave it wide open and just rely on the network to keep it safe (VPN/Firewall).
But if it's private in the sense of "our iPhone app uses it" then you definitely want to go with OAuth 2.0, or something like it.
2 legged OAuth is probably what you want to use. It's basically hashing a shared key, but you have the advantage of not having to write the code yourself.
Here's a related question: Two-legged OAuth - looking for information
You should use Oauth for mobile device to API layer communication.
However, there is no benefit of Oauth in this web UI layer to middle-layer access (machine to machine).
On the other hand there are some potential issues
Managing the access token expiry becomes a pain. Consider that your UI has to cache the access token across multiple nodes in a cluster. Refresh it when expired, and the fact that UI layer is negotiating security with backend will just take extra time once in a while.
In two legged Oauth (OAuth Client Credential as in v2.0) does not support any encryption. So you still need to send key and secret both to the server for getting an access token.
Backend has to implement issuing access token, refresh token, validating access token etc, without any significant benefit