-1

I am developing an app in which I have to fetch data through company provided APIs. All the authentication is done on their end, so I don't have to build my own APIs. However, There are some situations where they have some information, for eg: a new data entry notification, for us, for which they will hit an API provided by me. As there is no user/password possible at that time, I want to know how can I confirm if the hit on the API is a legit.

3
  • 1
    By definition, if there is no authentication then you cannot. There’s more ways than just user/pass, but without more details there’s little we can do. Commented Aug 11, 2021 at 1:22
  • 1
    One possibility is IP whitelisting on your end, but without more details, it's difficult to say for sure. Commented Aug 11, 2021 at 1:45
  • What's the concern? Why do you need to know if the caller is a legit one? What does your API when is consumed? Commented Aug 11, 2021 at 8:22

1 Answer 1

1

This a very broad question. The right answer for you depends on many factors, and you haven't given us enough information to help you work it out.

Recognise that if you want to service legitimate requests and refuse or deny invalid ones, you are doing authentication, and that means you are evaluating some sort of information about the requester to make your decision. The usual word for that evidence is "credentials". If you are not using a user name and password, you are still evaluating credentials in some form.

Where I would start is to answer the question "what is at stake?". If we are talking about financial information, credit card numbers, sensitive private etc. you need to take more care. If the worst that will happen with an unauthorised request is they discover high scores for some game, maybe you are not so worried about that.

As a couple of people have said in comments, you could filter based on the IP address of the caller.

If the request is arriving via HTTP, there are tools to help. If you are using some other network protocol, you might have to invent similar things for yourself.

You say there is no username or password possible, but I don't understand why that is so. It's quite common to include authentication information in an HTTP header. HTTP itself offers Basic and Digest authentication (https://stackoverflow.com/questions/9534602/what-is-the-difference-between-digest-and-basic-authentication) or you could do your own more customised scheme. If you do settle on HTTP Basic authentication, you really must use Transport Layer Security (TLS), because passwords are sent in the clear so anyone intercepting the request could discover the password.

You could give the caller an API token which they could include in the request, e.g. https://yourapi.example.com/newdataentry?apitoken=12345678 . For example Google Maps does this (https://developers.google.com/maps/documentation/javascript/get-api-key)

You could validate a certificate included in the request. You can generate a self-signed certificate and give it you your caller. You can validate the certificate when you receive it.

If you are willing to host your application on a cloud service, they have tools to help. I am most familiar with Azure but similar services are available on other clouds. Their Identity and Access Management (IAM) services can do a lot of the work for you. For example, on Azure you can create a Security Principal for their application and configure the secret or certificate they are using. You don't need to write the code to authenticate as part of your application. App Services on Azure includes EasyAuth (https://docs.microsoft.com/en-us/azure/app-service/overview-authentication-authorization) which does most of the work for you.

2
  • so there are kind of 2 ends here one is app and another one is the company.....company has users registered already...but they dont want us to access their system directly so they will be providing APIs. which we will use to authenticate users of app with their system. however there is a part which will be handled by us and company wont have access to that part "theoretically ". so whenever their is a data change on their server they want us to give them an api or something to notify our system. there wont be any separate system for that, api will be integrated to their old one so no id/pwd Commented Aug 12, 2021 at 0:33
  • So what I've decided now is using JWT token, to send request. so we will use a same key at both end to encrypt or verify data at both ends. data will be encoded using the key. only jwt token will be sent in the request, code will be verified at our end, if it verifies with our key then its valid and request is served else error Commented Aug 12, 2021 at 0:38

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.