Currently, I am doing an Internship at a Technology Company. The company is making a few Integration with ERP companies, some of the integration supports Webhooks, so my internship company implements it to do a handshake communication. As far as my research, webhooks work in different ways from API.
my hypothesis:
Webhooks can be attacked if the attacker knows the Url
my question:
is the webhook secure enough? Because data wash push from the
provider, how to ensure the data we get is from our trusted
provider?
Thanks in advance
Related
I am trying to configure Gmail API in a way so I can pull the inbox messages as well as respond against them. Basically, I am implementing a CRM and this one of the modules of that CRM. I got an email from Gmail verification support telling me that this needs to undergo a security assessment if your application can send Google suer data from a restricted scope to remote servers. For third-party security assessment, they mentioned that it may cost from $8,000 to $75,000. Is there some other way to tackle this? This is too much!
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 need a way to have decentralized authentication for my microservices using blockchain or whatever technology which facilitates decentralized authentication but without having to pay any transaction fee when user does a transaction.
I will elaborate it more.
If we use OAuth2 we need to have a centralized authentication server which will behave as a single point of failure for the whole system. Yes I can definitely validate the JWT token inside the microservice by maintaining the signature within the microservice without having to hit the authentication server again. But every initial request should go through the authentication server. I need to avoid that and have a decentralized mechanism there in place but without any cost implication.
Blockchain proivdes this facility but with transaction costs called Gas.
I then came across Hyperledger Fabric which doesn't have any cost implication.
Is it possible to use Hyperledger Fabric to authenticate users?
I will give you a scenario.
Let's say I have microservices written . NET. Now I need to authenticate the users. If there is a centralized authentication server then I will have a database table to keep user detail/credentials and when user tries to access a microservice the request will initially go through authentication server and user will be validated and then issue a token if successfully validated.
Can this be done in Hyperledger Fabric without using that centralized authentication server and user detail database?
Or are there any other technologies which cater for the above mentioned purpose?
Rather than for a implementation this is mostly for my knowledge and to get doubts cleared. Thanks in advance.
There is existing emerSSL - decentralized authentication blockchain-based system. In addition, there is existing authorizer.io - public gateway between emerSSL and any OAuth2 web-site.
Of course, you can deploy and maintain your copy of authorizer, or just use emerSSL directly, as same as it used on Emercoin demo pool.
Emercoin core wallet already has built-in GUI submenu to maintain your own emerSSL certificate.
First I would ensure that Web3 / blockchain is the best option for the problem you are trying to solve. You can do that by asking yourself three questions.
Is an Immutable Ledger the Best Fit for Your Back-end?
Does Your Back-end Work Best as Decentralized Computing?
Do You Need Scalability or High Transaction Volumes?
If you answered yes to all of the above questions, you should look into web3.js as a possible solution.
If you need help answering those questions or if you are looking for specific use cases where web3 is the correct solution, you can learn more here.
We're trying to figure out a best practice for IPC authentication and authorization. I'll explain.
We have a micro-services based architecture SaaS with a dedicated service for authentication. This service is responsible for doing the authentication and managing auth tokens (JWTs).
Everything works perfectly good with users that login and start to consume resources from the different services.
The question now is how to authentication and authorize requests which being initiated by other services (without the context of a specific user)?
Should we generate a dedicated user per service and treat it like
any other user in the system (with appropriate permissions)?
Should
we have a "hard coded"/dynamic token deployed among the services?
Any other ideas?
Our biggest concern is such tokens/passwords will be compromised at some point since requests from one service to another is treated with high level of permissions.
Cheers,
I'm not a microservices expert, just started to get my feet wet in the microservices world. From what I've read until now, this could be handled in many ways, one of which as you mentioned is hard coding api-keys so that services recognise one another. But I never liked this idea personally - also using a user per service like you mentioned. A solution I really liked is using Oauth2 for handling these scenarios - an interesting implementation I found is Gluu Server and I think client credentials grant type is what you're looking for - refer https://gluu.org/docs/integrate/oauth2grants/.
Have fun :)
Normally, API Gateway is integral part of any MS system.
All the services encapsulated and should be not accessible without API Gateway.
Such encapsulation allows direct communication between the services, without providing the requester payload, which should be required if the request comes straight from API Gateway.
In that case the request threated as something different, and follows different logic/middleware pipeline. No additional special users needed.
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