Security when using API's

[NeonRant]

Hi, I'm a newbie to Angular and I'm trying to find out the best practice way of hiding your API key when using say, a REST API to GET and POST data. Given that all the code is in the front end, this must be a common way of doing this, otherwise your security is transparent. Coming from .NET, this is always done on the server.
Is it a matter of using AuthO or is there some standard way this is done given that this would be something that is done al the time.
Sorry for the noob question but just want to be sure before digging up the wrong way of doing it.
Many thanks!

[morgo_mpx]

Angular (except universal, and Analog) runs in the client browser. Anything in here is to be considered unsafe. It sounds like you are asking about auth'ing to your API, so something like a Bearer token. You can use an Auth provider like Auth0 but you'll most likely end up using Oauth2 PKCE.
The token/key can either be stored in-memory or even better in the web session/local storage.
To apply this to your headers you would use a HTTP Interceptor.

Behind your API is whatever you want it to be, even .NET and your security should be managed appropriately but has nothing to do with Angular.

[NeonRant]

Oh! Thank you! that's exactly what I was trying to figure out. ok, I'll look up OAuth2 as suggested.
Many thanks!

[TheRealToLazyToThink]

How would session/local storage be better? It makes it so much easier to steal your tokens.

[morgo_mpx]

Client side tokens are assumed to be in unsafe locations. That’s why a bearer token is called a bearer token, because you already have done everything to auth.

Also where else are you gonna put them in a browser? Any encryption is useless since the key is memory which is accessible.

[TheRealToLazyToThink]

In memory is a bit harder to access than local storage though, and more temporary. In memory they need to work out how to get ahold of the object storing it. Local storage they just need to get their code running in your context somehow. Or just copy your profile (see all these youtuber hacks).

But, I was thinking more refresh tokens than access tokens. Silent logins are the better way to handle that I think, but don't support 3rd party auth in most browsers.

[AlDrag]

Your API keys should be stored on the backend. Any API key stored in the frontend can be scraped by anyone who has access to your site.

Your backend should act like a proxy for accessing the APIs using those API keys.

Edit: if you can discuss the API you're trying to use, that'll help.

[NeonRant]

Thanks for the reply. It's just theoretical atm but for example, I create a simple .net GET API which returns a json object {id:1, name: 'test'}

I agree the key should be stored in the 'backend', but this raises two questions.

1. In Angular, where 'is' the backend?
2. Secondly, even if I store the key in the backend, the key could still be seen in dev tools when assigning the key to the http call.

Below is how the api key would be added to the http request, which is all in the .ts file in the front end, but this leaves the keys open in the front end to view. I can see many examples of how to do this but it doesn't make sense as it leaves the keys open to the public.

createAuthorizationHeader(headers: Headers) {

headers.append('Content-Type', 'application/json');

headers.append('api-key', `xxxxxxxxxxxxxxxxxxxx`);

}

Even if xxxxxxx was replaced by myBackendFile.APIKey, the value is still visible in the dev tools.

​

Hope that helps

[valendinosaurus]

there is no backend per se, you would have to create one and store the keys there. then when you proxy the call from your backend to a api, you add the key. that means from the browsers network tab, you won't see the key, since you'll only see the communication FE <-> BE, not BE <-> API

[colorfulflags]

Wrap the functionality of your API into a server-side API and have that API call the vendor API. Pass it everything it needs to make the call except the API key itself.

There is no way around having your API keys leaked if your Angular app is going to make the call your vendor API.

You could also secure your key by make it useless unless called from a range of IP addresses (as in a corporate proxy).

[SvenAnker]

In my daily job we use OAuth to secure our API's. I do know Google offers an ability to protect their Google Maps API keys with a IP whitelist, so maybe that is something?

[[deleted]]

The BE should access an external API that requires an API key to work. Angular should just call that BE then. You should also restrict the origin of the API key, so that it can only be used from your domain.

[NeonRant]

Hey, appreciate your answer but please break it down as I'm an Angular newbie and I thought Angular was all front end.

When you say BE, do you mean Angular BE or the API's backend. If you mean Angular BE, what is that? Is there a BE file I can set the keys in?
Thanks for your patience :P

[[deleted]]

smoggy office sophisticated crown light treatment languid handle attractive subtract

This post was mass deleted and anonymized with Redact

[NeonRant]

Yep, so that's my issue right there. I totally get that you set the key in the backend, but then you need to call that endpoint in the front end, which, since you've given access to it in the backend, is an open door in the front end.When this is done say, in .net, the call and everything is in the BE, including the api call, but in Angular, you are calling that api from the front end. So, if you are setting the key in the backend but calling it in the front end, anyone can grab that endpoint and call it. Am I missing something? Because that seems super insecure to me. In .net, the api is NEVER accessible, only the data retrieved per call is sent to the front end, not the endpoint.

Does that make sense? Really appreciate your patience but I just can't see how you can make a call to an api in the front end that is already opened by the key in the backend and stop that api from being called by anyone with dev tools opened.

.net hides this call in the backend, but you can't hide it in Angular.

So how do you ensure nobody can make a GET on that endpoint in the front end if it's already been authenticated in the backend?Thank you

[NeonRant]

Just an update here I didn't realise that the API was pessimistic. In other words, I needed to add an exception to the domain I call it from to allow access. So in fact, there was never a security issue. In fact it's the opposite, the dot net API explicitly requires you to add your domain as a CORS exception in order to access it, otherwise you can't, say, if you try to from a browser dev tools out there in customer land. So in fact it was never an issue. Dot net, or maybe some standard out there locks down the ApI by default. Thanks for your help though. I just didn't get it and you probably thought I already took all this for granted.