1

I will be creating an Angular app that will make calls to a DotNet Core API I have created. Because the API itself calls a third-party API which needs to be secured with an API key, I want to secure my API so that no one else can call my API without authorisation.

To this end, I thought I could just have a single-use username and password that the Angular app would append to each call it made to my API - i.e. there will not be a login page.

What is the recommended way of achieving this? I do not yet know where (or if) I will host this publicly, but I may deploy it in Azure in some fashion eventually.

Options seem to be:

  1. Storing the username and password in web.config and then possibly encrypting the file (I'm actually not sure whether I'll eventually decide that having a plaintext web.config file is fine or not, but I'd just like options for now) - see https://www.infoq.com/articles/Secure-web.config. However, I'm not sure how I'd decrypt this in Angular.

  2. Encrypt and decrypt an environment file that Angular will use - see https://medium.com/nontechcompany/secure-angular-configuration-credentials-in-containerized-environment-as-of-2021-a7f36ed676ed and linked articles https://betterprogramming.pub/how-to-secure-angular-environment-variables-for-use-in-github-actions-39c07587d590 and https://javascript.plainenglish.io/setup-dotenv-to-access-environment-variables-in-angular-9-f06c6ffb86c0, though these seem to be for "containerized" deployments, and I'm not 100% sure I understand how they work just yet.

  • don't understand your question... why your want to secure your own API and then want the credential to be exposed to user app? And securing your own API is nothing to do with the API key for 3rd party, as that API can be secured on your API project and why it can be spoofed? better to rephrase the question. – Vincent Dec 29 '22 at 12:37
  • So, I only want my web app to call my API. The single user that the web app uses will have the correct role to access my API endpoints. My endpoints do calls to the third-party API, which means if anyone can call my API without authorisation they will also be making calls to the third-party API with my key, which I want to avoid. The third-party API key is stored in a SQL db, but is implicitly used every time a call to my API happens. – Mahendran Nadesan Dec 29 '22 at 12:53
  • Okay. It seems you want a public served frontend to access your API but needs to be secured, without a manual authentication process? I think there it is contradictory against the word 'authentication' logically. – Vincent Dec 29 '22 at 13:23

1 Answers1

0

I would recommend you to generate a JWT signed token from your api on the initial user login.

As you said, you have a custom API between the client and the third party API so why keep the sensible data client side ?

If you need to use the plain text username/password server side, you can still hash / decode the JWT token and retrieve user infos to interface the third party API.

That way you don't have to store any user credentials / sensible data client side and expose it in client api calls, you'll have to deal with only a token you can store in a cookie or localstorage.

✌️

  • I should have mentioned that I considered this, but then what would the expiration of the token be? Would it never expire? And if it did expire, I would have to put in custom logic to re-authenticate and get a new token every so often. I'll consider this, but only if I can't get a more appropriate solution. Thanks. – Mahendran Nadesan Dec 29 '22 at 12:48
  • The answer to that is the refresh token, you can use it to get another token when the first one expires. You will find an appropriate answer about the JWT refresh token flow here: https://stackoverflow.com/questions/27726066/jwt-refresh-token-flow – Yusuf Gokol Dec 29 '22 at 12:53
  • Sorry, I just reread your answer. You say I should use a JWT created from the "initial user login". But I don't have a login page, and don't plan on having one. I will still try to "login"/authenticate, but I want to do it without having to go to a page and entering the username and password. If I absolutely have to, I will create a login page and do this, but I would rather not. I will look into the refresh token though, thanks. – Mahendran Nadesan Dec 29 '22 at 12:59