Let me clarify my use case:
I have a next.js application which is a plattform for listing real estate objects. I have several api routes which im using inside my next.js app. for example:
/api/createpost ->
Takes informations from my form on my next.js app and creates a database entry to perform a new post
/api/getposts ->
fetching all the real estate posts from my database and displays it
/api/login ->
logs in a user by checking the credentials in the database and sends a jwt
/api/register ->
registers a user by taking the credentials from a form from my next.js app, registering a user and creating an entry in my database
Now in order to secure my apis I want to make sure to check if there is a valid user session if anybody is calling one of the apis (except the register/login api) to get the expected result. Im doing this by calling the /api/login route and getting a valid user session. Until here everything just works fine. Apis like the /api/createpost can only be called if we have a valid user session.
Now I want to create a mobile app and I want to use my api routes from above to provide full functionality in my mobile app too. It should work the same, if i want to call the /api/createpost on my mobileapp for example, i need a valid user session.
But I want to restrict my api by asking for a key in my database which is pointing to my app and saying okay if you call the /api/createpost api, first of all i need to verify that its the mobile app asking. The mobile app will provide the key in the request then.
I didnt try this yet, but it should work i think. Now the big mess: If we call the /api/createpost and the api wants a valid token to check in the database, which will work for the mobile app, because we are giving it a valid token to check in the database, how can we provide a token if we are calling the api from inside our next.js application? Since I have to do the api call clientside, there is no way for me to provide a secret key or something to validate that the call is coming from my next.js application.
If your application is private
(to be used only by you or a few select people)
You can send a private API key over SSL with each request from your application to the server and verify it. Or you can limit your API to only accept requests from certain IPs.
If your application is public
Unfortunately there's no way to determine where the request is coming from, since anything your app can send, an attacker can send it manually.
Think about it, if your app is trying to make a request to your API, any user can intercept this request before its sent out of his/her machine, and send the exact same request from a different app on the same machine.
You might say, well I can encrypt the requests and responses so that they are of no use to the attacker. But such an encryption will require either a key that's already agreed upon, or some way to provide a new key at the beginning of each session.
If the key is already agreed upon, the app must contain it, as you've already guessed in the question, the attacker can retrieve this key no matter how well you try to hide it.
If the encryption key is a new key provided at the beginning of each session, that's almost how SSL works, your browser handles this transaction. Your server sends a public key to your browser to encrypt the requests which the server can then decrypt with a private key. In this case you've circled back to the same problem, how can you verify to whom you give out an encryption key? What would stop an attacker from requesting the encryption key?
There has to be some way you'd be able to design apps that don't require this restriction. I think the question you should be asking isn't how to restrict your api to a certain app, but how to design apps that don't require this restriction.
We might be able to help you out if you could tell us why you need this restriction.
Update
There is actually a way to verify that requests are coming from your app, but not with an api key.
For Webapps
You can use Google's reCAPTCHA to verify a user on your /register and '/login` routes, and provide an access token or start a valid user session on successful captcha response. With reCAPTCHA v3, you could even verify every user action without interrupting the user. This eliminates both the problems I mentioned in my answer above -
You don't have to store an api key into the app/web app.
The request can't be spoofed as it requires human user interaction within your app. The captcha verification success will arrive to your API from Google's reCAPTCHA server, not from your client app. This communication will be authenticated with a pre-mediated private API key shared by Google to you, which works in the same way as to how you authenticate your external domains.
For Android apps
A similar way to achieve the same thing would be via Android SafetyNet Attestation API. This checks the runtime environment and signs the response with a dynamically generated nonce that your app provides the SafetyNet API.
Please read its docs carefully to understand how you could create potential security loopholes and how to avoid them while using this API.
For iOS apps
DeviceCheck works in a similar way, except the device validity is provided to you by Apple server.
Important edit: "secured" is not the right word here! You cannot tell that a request comes from your app just because the domain is yours. The domain name is not a safe information, as it can be altered easily. See #Mythos comments below.
Initial answer:
Web applications access is secured not based on an API key, but based on a whitelist of domains. That's how we achieve security, because only you have access to the domain where you host your own application: so the request has to be coming from an app you own.
If you try some 3rd party services that provides API for web apps, that's often how they'll work: they will let you configure a set of whitelisted domains that can access your data.
If they provide you an API key, this API key is always meant to be used by a server, not a client-only app.
So if I understand you question correctly, you would do like this for each request:
Check the domain. If it's in the whitelist, perfect, you can keep going. This is meant for web apps (look for "CORS").
If not, check for a valid API token in the headers. This is meant for any app that can store this API token securely (another server for instance, or a mobile app in your scenario though I don't know mobile enough to tell how you store such a key)
I am new to Firebase. I have linked Firebase to my React Native app, the Auth part is working and in the SCOPES array I am passing necessary scopes for sending emails https://www.googleapis.com/auth/gmail.send.
The Problem: On backend I am using Node.js and a Google Cloud project for sending emails, the way I wan this to work is that I will be sending a POST request to backend with the access token of user's account and then using that access token to send emails.
Is this something possible? I am basically using 2 different projects, one Firebase project for Authentication and giving Gmail permission and then another Google Cloud project for sending emails. I have whitelisted the Email sending project in Firebase Auth project.
Is this something possible? Is there any better way to achieve this?
Using firebase we have integrated OTP service for user to register & login in our web app. Is it possible to integrate IVR service also for users registration & login. Pointing to document reference would be helpful. I could not find one in firebase documentation.
Used Angular as front end and node as backend in our project,
Thanks,
Mohan
Firebase Authentication comes with a number of built-in providers, for email+password, many social sign-in services, and phone number based verification. But there is no built-in provider that uses interactive voice response (IVR) to sign the user in.
That said, if you have an IVR provider you want to use, you can build a custom provider to sign the user that you authentication with that service into Firebase. See the documentation for what that looks like in your app, and on the back-end that you'll need to create.
After authenticating my user using Firebase, I have the user object (which has a Uid, which can be got using getUid. I also have his phone number.
But each time the app makes an http request to my site, how does my site know it is talking to my app, and not someone pretending to be my app ?
Does firebase have any feature where I can use some token or something when communicating with my app ?
You need to use tokens:
https://firebase.google.com/docs/auth/admin/verify-id-tokens
You get a token from firebase, and send it to your server. Your server checks with Google if the token is authentic.
I am developing a system like Online Exchange(olx). This system require a verification from the user that the number entered by the user in ad is correct or not. for that purpose I want my system to send a message to the number given by the user with a verification code.
How can I implement this system in asp.net?
You can't send an SMS on your own.
Rather, find a service provider in your country and contact them. Providers offer paid services that are usually exposed as web services.
Technically, your application calls a provider service over http[s] and you pass a phone number and the message body. There are usually multiple payment methods, for example you can pay for a message pack or your clients can pay on their own by first sending their message to a fixed number.