azure app service Azure App Service - Client authentication to use API

[SoftwareNinja]

Hi All,

 

I have being looking into authentication to use on API I am working on but I lack experience in this area.

 

I have developed an ASP.NET Core application that is hosted on Azure. Is there a way to integrate authentication for clients I define within the Azure Portal?

 

I want that we create a client within Azure and we provide them with a Secret Key to use in order to obtain an access key that Azure Provides.

The secret key would be used within the Header of a HTTP Request.

 

Currently I have created authorization using the likes of a Microsoft account to signin with but because there will be no front end area to sign into, I'd like to be able to manage the secret keys from Azure.

 

I hope this makes sense and someone can point me in the right direction. Thank you in advance! 

 

[Eigenvektor]

Does your .Net application provide the API? Why not have that service accept the secret key (i.e. API key) directly and use that as authentication? This way you're not strongly bound to Azure and can move your service to other providers if needed.

 

Other ways to do that would be to integrate some kind of username/password authentication into your app or use a mechanism like Security Assertion Markup Language (SAML) or OpenID Connect (OIDC). Pretty sure there's .Net libraries out there to handle the heavy lifting.

 

In all cases you'll want to use HTTPS rather than plain HTTP to make sure your secret keys etc. actually stay secret.

[SoftwareNinja]

27 minutes ago, Eigenvektor said:

Does your .Net application provide the API? Why not have that service accept the secret key (i.e. API key) directly and use that as authentication? This way you're not strongly bound to Azure and can move your service to other providers if needed.

 

Other ways to do that would be to integrate some kind of username/password authentication into your app or use a mechanism like Security Assertion Markup Language (SAML) or OpenID Connect (OIDC). Pretty sure there's .Net libraries out there to handle the heavy lifting.

 

In all cases you'll want to use HTTPS rather than plain HTTP to make sure your secret keys etc. actually stay secret.

The main reason for using Azure services is the extra layer of security. This is not a personal project but in fact for the company I work for and we use Azure for everything and we won't change from that as we have heavily invested into Microsoft cloud a few years ago.

 

With creating our own keys and validation comes a lot of security and documentation for our SOC 2 Report.

This is a small company so we wouldn't have a large team for security but the Likes of Microsoft have a massive team creating security for Azure Services which we can use in our leverage.

[Eigenvektor]

13 minutes ago, ScottDurkin said:

The main reason for using Azure services is the extra layer of security. This is not a personal project but in fact for the company I work for and we use Azure for everything and we won't change from that as we have heavily invested into Microsoft cloud a few years ago.

I'm not criticizing your use of Azure services, we do to, along with AWS. However security is still integrated into our product, because our software can run on different services (containerized) and our customers can also run it on-premise. Instead of inventing our own, we use the security layer built into the framework we're using.

 

13 minutes ago, ScottDurkin said:

With creating our own keys and validation comes a lot of security and documentation for our SOC 2 Report.

No need to invent your own. As I said, there's standards like SAML and OIDC you can use (think SSO) and I'm almost certain there's .Net libraries for that. In fact we have several customers that insist on running their own IdP, so our software has no access to login credentials, it simply authorizes users based on their authentication with the customer's infrastructure.

[SoftwareNinja]

48 minutes ago, Eigenvektor said:

I'm not criticizing your use of Azure services, we do to, along with AWS. However security is still integrated into our product, because our software can run on different services (containerized) and our customers can also run it on-premise. Instead of inventing our own, we use the security layer built into the framework we're using.

 

No need to invent your own. As I said, there's standards like SAML and OIDC you can use (think SSO) and I'm almost certain there's .Net libraries for that. In fact we have several customers that insist on running their own IdP, so our software has no access to login credentials, it simply authorizes users based on their authentication with the customer's infrastructure.

Ah yes, I understand. Apologies. Thank you for the reply