I have my Rest API's configured in API Gateway. I want to implement OAuth on top of it so that the access to the url's are authenticated. I know that Lambda functions will be required here. Following are my questions:
1. Any good third party oauth providers that I can link with my project?
Scaling needs will be pretty high, possibly around 1M/second. Will these providers be scalable enough?
I would want to be doing everything programmatically. Like mostly these providers will require registration in order to acquire client id's and secrets. I want that also to happen programmatically as the no of users signing up will be dynamic.
i find Authlete good and also provide a guide for Amazon API Gateway
Yes, they can scale pretty well (check the pricing section) if you are willing to pay enough
Related
There are primarily two ways to authenticate using Google's reCAPTCHA Enterprise in a non-Google cloud environment (we use AWS). Google recommends using Service Accounts along with their Java client. However, this approach strikes me as less preferable than the second way Google suggests we can can authenticate, namely, using Api Keys. Authenticating via an Api Key is easy, and it’s similar to how we commonly integrate with other 3rd party services, except rather than a username and password that we must secure, we have an Api Key that we must secure. Authenticating using Service Accounts, however, requires that we store a Json file on each environment in which we run reCAPTCHA, create an environment variable (GOOGLE_APPLICATION_CREDENTIALS) to point to that file, and then use Google's provided Java client (which leverages the environment variable/Json file) to request reCAPTCHA resources.
If we opt to leverage Api Key authentication, we can use Google’s REST Api along with our preferred Http Client (Akka-Http). We merely include the Api Key in a header that is encrypted as part of TLS in transit. However, if we opt for the Service Accounts method, we must use Google’s Java client, which not only adds a new dependency to our service, but also requires its own execution context because it uses blocking i/o.
My view is that unless there is something that I’m overlooking--something that the Service Accounts approach provides that an encrypted Api Key does not--then we should just encrypt an Api Key per environment.
Our Site Key is locked down by our domain, and our Api Key would be encrypted in our source code. Obviously, if someone were to gain access to our unencrypted Api Key, they could perform assessments using our account, but not only would it be exceedingly difficult for an attacker to retrieve our Api Key, the scenario simply doesn't strike me as likely. Performing free reCAPTCHA assessments does not strike me as among the things that a sophisticated attacker would be inclined to do. Am I missing something? I suppose my question is why would we go through the trouble of creating a service account, using the (inferior) Java client, storing a Json file on each pod, create an environment variable, etc. What does that provide us that the Api Key option does not? Does it open up some functionality that I'm overlooking?
I've successfully used Api Keys and it seems to work fine. I have not yet attempted to use Service Accounts as it requires a number of things that I'm disinclined to do. But my worry is that I'm neglecting some security vulnerability of the Api Keys.
After poring a bit more over the documentation, it would seem that there are only two reasons why you'd want to explicitly choose API key-based authentication over an Oauth flow with dedicated service accounts:
Your server's execution environment does not support Oauth flows
You're migrating from reCAPTCHA (non-enterprise) to reCAPTCHA Enterprise and want to ease migration
Beyond that, it seems the choice really comes down to considerations like your organization's security posture and approved authentication patterns. The choice does also materially affect things like how the credentials themselves are provisioned & managed, so if your org happens to already have a robust set of policies in place for the creation and maintenance of service accounts, it'd probably behoove you to go that route.
Google does mention sparingly in the docs that their preferred method for authentication for reCAPTCHA Enterprise is via service accounts, but they also don't give a concrete rationale anywhere I saw.
We are trying to build an API gateway in front of our application (we may split the application to micro services ASAP), and we meet some problems.
1 - different API types.
There are two kinds APIs in our application, most of them will be used by ourselves(user login/logout, news add/remove), we call them Self-used API here. And some of APIs will be allowed to used by third party, we call them Open API here.
Should all of them get through the gateway?
2 - different authentication
Self-used API may require the user login-ed or have related permissions, the Open API will require the third-party app take a key which we will use to identify and limit the request rate.
Should all kinds of authentication completed in the gateway? If yes, the Self-used api authentication is business related, does it mean that this api gateway can not be shared by other application?
Furthermore, the third-party developer will create their application and get a key back, they can also update/remove the apps(Something like Google API Console).
I am not sure if this should be put in the gateway or another micro-service. IMO, I prefer to put these features in a new service, but the validation and rate limit is done in gateway, that means for each request, gateway will have to query the user, rate limit and other information by the key from the service, this will make the gateway coupled with the business again.
There are quite a few ways of implementing an API Gateway. You can use different endpoints with a single API gateway. Here are a few links that are relevant
Serverless blog "How to deploy multiple micro-services under one API domain with Serverless" https://serverless.com/blog/api-gateway-multiple-services/
Nginx "Do You Really Need Different Kinds of API Gateways? (Hint: No!)" https://www.nginx.com/blog/do-you-really-need-different-kinds-of-api-gateways-hint-no/
Sentialabs.io "Amazon API Gateway types, use cases and performance" https://www.sentialabs.io/2018/09/13/API-Gateway-Types-Compared.html
AWS API Gateway FAQs https://aws.amazon.com/api-gateway/faqs/
Think about the types of features you are trying to accomplish with your approach, and how API Gateway will help you address them.
I'm working on a RESTful API, that works as backend for a mobile application.
The underlying system is based on Jersey and Jetty server, but my question is more generic (for any JaX-RS compliant system).
I'm looking for a standard solution to secure it. I read about many answers talking about JWT, tokens, ... and OAuth.
But all solutions except OAuth do not have a Standard and neither any implementation apart from some basic examples on github.
I'm concern as OAuth seems a good solution for third party access on your API but I think is a great overhead for straight access & tokenization, from a Mobile app or a Website AJAX. Is hard for me to accept that is the only available solution.
Here I'm asking, am I wrong about OAuth (beeing designed for third party access)? or other access solutions are not available (eg opensourced) as they are only custom made for the specific purpose?
My scenario requirements:
Token should be self certified (eg JWT) so a proxy/load balancer can filter out a not signed one, before reaching the endpoint.
No need for a token/renew system as we have a distributed cache holding a SESSION and therefore a missing session mean that authorization expired/was revoked.
The second one, may not be true as if we issue a certificate to an App for 1 year, and revoke it after 1 hour. This token may be still used by an attacker to "frustrate" our cache for 1 year.
Iam a student and i making my internship. Sorry for my bad englis
The situation
2 people are building an backend for an message system. There are actual and passed messages. The main backend contains all the data from all the messages. This backend pushes only actual messages to and database from an mini backend which only contains the actual alerts. These actual alerts are provided by an api to multiple front ends such as an app.
I need to do research about api gateways which can make the data in the mini backend accesable for external developers. These developers only need to register or request an account so we know which application/developer connects with our api. We don't have end users with user accounts.
The API need to be scalable because in the future (over a couple of months) this system wil replace an old system. The current system needs to be handle more then 5.000.000 requests in a couple of minutes when sending out an emergency message/alert.
My problem
I googled a lot about authentication methods and i read about OAuth2. This is only necessary for authenticate end users with an user account? I dont have that so OAuth is to complex for my situation i think. But when i look in the documentation of several API Gateways like Mulesoft, Amazon API Gateway and some more i always come back by OAuth and not by an simple authentication token system or something.
See this link and then Creating a client registration flow. This uses OAuth or do i understand this incorrectly?
So now my questions
Is there an default method such as google or facebook uses for authenticate external applications by an API key? and how is this method/framwork/idunno caled?
Is it posible that i can/need to do this with OAuth?
Some example API gateways that can fill in my wishes will be great!
Amazon Api Gateway team here.
Our service supports native API keys which satisfy simple use cases. Are you interested in a simple mechanism to authenticate clients when they access your API? Some limitations would be that it's harder to manage a large number of keys, and there wouldn't really be any authorization to specific backend resources, only authentication to access the API in general.
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-api-keys.html
OAuth is better for dynamic user bases where new users register and you want to be able to control access for existing users over time. It is also useful when users have personal data that only they should be able to access.
Jack
I am in the early stages of planning (in particular for the security) of a REST API through which a mobile application authenticates and then sends data to be stored in (and also to be retrieved from) the Joomla website/database. It's basically an application-to-application authentication.
I plan to use the API for own internal use which means that the otherwise important aspect of "making it easy for third party developers/API users" is not as important. My main concern is that I of course want to prevent that illicit information can be injected through such API calls. At some stage I might also be asked by external auditors about how this security aspect is properly covered - hence I better be prepared from the start... ;)
SSL is planned to be used for client/server communication and the API will also use a username/pw for authentication, But does anyone have an opinion about (and maybe experience with) using OAuth as a security layer? I do not mean using user's social media pw for the Joomla login, I mean implementing oAuth on the Joomla Component side (i.e. the Joomla side REST API).
Thanks
This is exactly what we have done at our organization. It would have been nice to follow some existing OAuth (I assume OAuth 2) implementation using Joomla but I don't think it exists other than vanilla php implementation. We used this active project but built our own from scratch. This project takes into account all Grants and I suspect if you are doing mobile app authentication like us you will stick to the Resource Owner Password Credentials Grant. So it really depends on what you are doing.
So the first part was authenticating with Joomla from our mobile app. Here is a post on the start of that. With that we followed the spec RF6749 to follow the convention needed and produced the proper Bearer Token etc.
Then it was a simple matter of doing what was needed for the mobile apps with the REST APIs.
I'm over simplifying it (especially since I'm recommending going through the RFC carefully) but once you know how to authenticate with Joomla, your sailing. IMO.