Azure Security - barialim/architecture Wiki

Original URL:

Table of Content

Table of contents generated with markdown-toc

Network Security Group

Azure Private Link

Azure Private Endpoint

Azure Private Endpoint sometimes also called Private Link, is a network interface for completely connecting privately and securely to Azure PaaS services (i.e. Azure Blob storage, Redis cache, etc.).

Its a cool technology that allows us to use traditionally PaaS services resource as part of Private VNet. And what this allows us to do is to have better security platform on Azure without having to use the Public Internet to access many other traditionally

What is actually actually provides

Azure Private Endpoint Use Case

Azure Private Link Use Case

  1. Suppose your business ABC had an application running on a Virtual Machine in your own dedicated Virtual Network.
  2. This application is only accessible through a private IP address
  3. The backend storage for this service is hosted on an Azure Blob Storage. So in this case, we know that the VM has its own private IP address of, and the Azure Blob storage does not have a private IP, it uses Public IP.
  4. Suppose the original chef on-premise had a Private IP of, and wanted a mechanism to access the blob storage from on-premise.
    1. One option is to access the Blob storage from on-premise is through Express Route - Microsoft Peering domain, BUT the blob storage account still had a PUBLIC IP address, and the security team was not happy about it. The organization Rule dictate that they'll not be opening any public IP access on their FIREWALL. How do we solve this?
    2. We can solve this using Azure Private Link!
  5. In order to access PaaS service securely, lets understand what is required?
    1. Create Private Endpoint inside your Virtual Network. Its a "NIC" card inside your private IP space, in this case it'll be a private IP
    2. Next we'll create a Private Link Resource. That is our blob storage account.
    3. We then connect our Private Link resource to the Private Endpoint using Private Link.

    Private Endpoint --> Private Link --> Private Link Resource (aka Azure Blob Storage Resource)

    1. This way the traffic intended to the storage account always remain in the Private IP space, and it does not need any Public endpoint what so ever in order to access it from on-premise, or from the Azure Virtual Network.
  6. Next concern for Security team is Data Exfiltration (see terminology).
    1. In otherword, can anyone from "ABC" use this Private Endpoint to leak confidential data to other storage accounts?
    2. The answer is "NO", and that's because you'll only tie specific Azure resources (Azure blob storage) to this specific Private Endpoint, thereby protecting data exfiltration.

    ⚠️ Note: here is link to Azure resources that are currently working with Azure Private Link.

Watch the video to understand Private Link

Watch the video

⚠️ Note: Private Link carries traffic privately, which reduces your exposure to threats and helps you meet compliance standards.

Hybrid Identity

Managed Identity

Manage Identities is a great feature of Azure AD. Make sure you review the availability status of managed identities for your resource/service and known issues before you begin.

Managed Identity service is built for Resource:Resource communication without having to managed credentials i.e. Service Principals.

Managed Identity is nothing but a wrapper on top of your service principals.

Two Managed identity types:

Managed Identity is tied to an Azure Resource and is Not User specific.

When Managed Identity service is created, its Read-Only. It has Client_ID & Object_ID.

A common challenge for developers is the management of secrets and credentials to secure communication between different services.

Managed Identity can be used to perform secure authentication to any Cloud service while maintaining NO Credentials in your source code.

On Azure, Managed Identities eliminate the need for developers having to manage credentials by providing an identity for the Azure Resource in Azure AD and using it to obtain Azure AD tokens.

To better understand Managed Identities, let's understand some classical scenarios on how we would perform AuthN in most Azure Services.

Using Keys for Service:Service AuthN

Service:Service AuthN using Keys

  1. Two Service communicating with each other; Service A (client) sending key to Service B (server)
  2. Service B validating the key; checks permission and authZ this key
  3. Returns the result

Fine-graining: permissions

Storing: those in your App code

Pretty simple, but as you can imagine this imposes some challenges (see above Managing Keys) and highest security risks. Because usually those keys are stored in your service configuration files, and while you can move the keys out of your configuration file into an external service like Azure Key Vault which off course you should do, but again that would leave you with a challenge of how you can securely connect to Key Vault without maintaining any keys; any credentials within your source code/configuration file. This brings use to the second case using Azure AD for Service:Service AuthN.

Using Azure AD for Service:Service AuthN

Service:Service AuthN using AAD

  1. Service A sends identity credentials to Azure AD in order to connect to Service B
  2. Once those credentials are validated by Azure AD, it returns a Token
  3. Service A only then sends this token to Service B 4 & 5. Service B, who will then connect to Azure AD to get Open ID configuration
  4. Service B will then verify the Token and its AuthN layer
  5. Result is return to Service A

This provide much better security compare to using Keys bcoz Azure AD has bunch of features around security and smart alerting. But we're still left with one more challenge here of storing this identity credentials somewhere; and they're either present within App code, configuration file, or on the service itself. So we'll some how need to avoid management of credentials within our service.

To solve this we can use Azure AD Managed Identity.

Using Azure AD Managed Identity

Key Service Characteristics

Let's take the previous example of connecting 2 services together using Azure AD Managed Identity this time

Service:Service AuthN using AAD Managed Identity

This time we'll have an Application (replace Service A) on a Azure VM connecting to a Key Vault (replace Service B) service.

In this case, the application will still continue to grab a token from Azure AD. When you enable Managed Identity, a locally running internal endpoint will be registered (Managed Identity Endpoint).

Managed Identity Endpoint

MI Endpoint is a small web service running on that VM that is only accessible from within that VM. So only your locally running code can access this web service to request token from it`

  1. Your application (service) sends a request to this Endpoint to request a token from it with NO Credentials to this endpoint
  2. MI Endpoint service will use internally stored credentials on that VM to connect to Azure AD to grab a token from it
  3. AD returns the token to MI Endpoint service
  4. MI Endpoint will then pass the token to your Application
  5. Application makes a request to Key Vault service along with a token 6 & 7. Key Vault service will then validate this token against Azure AD
  6. In the case of Key Vault, additional Token verification is done like Access Policy Verification are done
  7. Once everything is OK, a Secret or anything you've requested will be returned to Application

As you can imagine we can imagine we've solved the issue as in our Code we've NO Credentials anywhere, because that request our Application send to MI Endpoint has NO credentials in it.

Additionally one thing to note that, when you register a Managed Identity; the name of that identity will be the same as that service/resource in Azure. So in the case of this Azure VM, the name of Managed Identity will be the same as your VM name.

Last but least, the Managed Identity life-cycle is tied to the resource (in this case VM). So if you're going to delete this VM, the identity & service Principal (Object ID) with Azure AD will also be deleted.

Service Support by Managed Identity

When exactly to Use it?

Type of Managed Identity

They are the same in the way they work.

The only difference is that if you enable System-Assigned Managed Identity for an Azure resource, the Managed Identity gets automatically created and assigned to that Azure resource, and will also get deleted when you delete the resource.

User-Assigned Managed Identity is created manually and likewise manually assigned to an Azure resource. The lifecycle of a User-Assigned Managed Identity _**is NOT tied **_to the lifecycle of the Azure resource to which it is assigned.

That means it the Azure resource gets deleted, the User-Assigned Managed Identity will not be deleted from Azure.

When do I use Managed Identities

When can I use Managed Identities

Alternative AuthN services

There are alternative Authentication services to access Azure resources. Here're some of those:

  1. Service Principal

  2. Shared Signature

  3. Account Key/ Access Key / Master Key

Note: For most of the scenarios, above is the order of precedence. In some cases Service Principal takes precedence, for scenarios like for the same Azure resource we need to give different permission for different users. Because Managed Identity will be tied to resource, can’t control in the way of user specific.

Service Principal

Managed Identity manages the creation & automatic renewal of a service principal on your behalf.


Encryption is a method by which a plaintext or any time of data is encoded. The encoded data can only be decoded by the person who has the decryption key.

The encrypted data is referred to as the cipher text, while unencrypted data is called plain text.

Data can be compromised both in-transit and at-rest and this data requires protection in both cases.

Hence, encryption plays a major role in protecting data, and there are various different approaches to protect this data both in-transit and at-rest.

As mentioned above, one of the most effective data protection methods for both data in-transit and data at rest is data encryption.

In Transit

In transit data is when it's moving from one system to another system.

System = Application, browsers, web connections, or database

Other names data in Transit

For protecting data in transit, organizations often choose to encrypt sensitive data prior to moving and/or use encrypted connections (HTTPS, SSL/TLS, FTPS, etc.) to protect the contents of data in transit.

Please see more about Azure encryption overview.

At Rest

At Rest data is data that is not being accessed and is stored encrypted on a physical/logical medium such as database, cloud or hard drive for later retrieval.

For protecting data at rest, organizations can simply encrypt sensitive files prior to storing them in a database and/or choose to encrypt the storage drive itself.


Data in-use is when it is opened by one or more applications for its treatment or and consumed or accessed by users.

End to End Encryption

E2EE is when NO ONE is able to monitoring the network, or can see the content of your data when sent over a network Not hacker, Not the Government, Not even the Company (e.g. WhatsApp) that is facilitating the message to sender. It's stronger then encryption in-transit.

A good example of this is WhatsApp messaging app, where when you send a message to someone, only the receiver is able to read the encrypted message in a plaintext format. WhatsApp cannot read this message.

Customer Managed Keys

Is also known as key management with Azure Key Vault.


OAuth 2.0

❓: Does OAuth means Authentication or Authorization?

OAuth is nothing but a standard for Authorizing one system using another known service (like Facebook/Google) Authorization Server to provide User details to System A on behalf of user. This is also known as Access delegation.

OAuth is an Open standard for System:System Authorization.

Some people also refer to OAuth as a delegated authorization framework for REST/APIs. It enables apps to obtain limited access (scopes) to a user's data without giving away a user's password.

You must have encountered OAuth for example when you try to register to an e-commerce site, and this e-commerce site gives you an option to use well known social media authorization servers like Facebook, Google etc. to authorize them to share your profile data with this application that you would to register with.

How does it work?

Suppose Alex is a developer who has been told he needs to use OAuth 2.0 to authorize users of his application by using Bank's external authorization server. John application will delegate the responsibility of his user authorization to some other service rather than managing them on his own.

First let's understand high-level roles exist within OAuth 2.0, we've...

So for example if you wanted to listen to a music on Spotify, you might have chosen to login to Spotify using Facebook/Google account.

Spotify is the Application and Facebook is the API in this case. So for John's case, the application is his application, and API is the Bank's API he would use.

So in the case of John, he'll be like...

"I get it now. When I log into Spotify with my Facebook account, Spotify grabs my username and password from Facebook. So easy, right?" The answer is WRONG ❌ This is the biggest misconception about OAuth 2.0 framework. Passwords are NEVER passed from server to server in an OAuth 2.0 framework.

How does two system know/trust each other?

  1. System A will need to Register as a Client with System B (Authorization server like Facebook/Google)
  2. Client will be given a unique Client ID and Client Secret which is used when authenticating a system with another Authorization service provider server like Facebook, Google.

What does OAuth workflow looks like once a System A is authenticated with System B?

  1. User asks System A to grab his profile details from System B Authorization Server
  2. System A asks System B (Facebook) to access users profile details on their behalf
  3. System B goes and asks the User, that System A is asking for permission to access it's profile details
  4. User cam either accept/reject granting permission to System A
  5. If User grants permission to System A, then System B sends an Authorization Token (limited access)
  6. System A saves the token, and uses this token every-time it calls System B when it needs to access user profile

OAuth 2.0 Grant Types

There are Four different types of grant types in OAuth 2.0. The grant type used above is Authorization Code Grant.

  1. Authorization Code Grant
  2. Implicit Grant
  3. Password Grant
  4. Client Credential Grant

What does OAuth token looks like

It has to be a token that contains the following two information:

  1. Information about user-allowed permissions
  2. There also needs to be something that the services can verify known as Trustable (cannot be tempered)

Benefits of OAuth 2.0


Now you understand why OAuth is used for Authorization ✅ and NOT Authentication. ❌ The problem is not Authentication, because the user is already authenticated to both systems. Hence, the problem OAuth is trying to solve is Authorization.❗

OAuth Terminology

JSON Web Token (JWT)

Is a very popular way to do Authorization in web applications in today's world.

JWT is nothing but a JSON object. Its a way for a client and server to communicate and share information directly that has some meaning across multiple interactions without the server having to remember information for each client. It is used for Authorization purposes.

It is commonly used for Authorization. The idea behind JWT is to create a standard between two parties to communicate securely. So there is this open standard specification called RFC 7519, which outlines how a JWT should be structured, and how it should be used for exchanging information.

Other Authorization options/strategies

Why is Authorization token required

This is all because of HTTP as it's a stateless transfer protocol. No state is maintained over a request. A user calls a URL, then server responds back with an HTML page.

Token is required when you send a request to a server along with your IDENTITY to tell the server who you are.

How is session ID stored on client side

Session ID gets saved in a cookie, so that it automatically gets added to the cookie header on subsequent request.

SessionID + Cookie vs Sticky Session vs JWT

Let's understand why JWT is better than SessionID (+ Cookie) or Sticky Session authorization strategy❓

The biggest problem with Session ID + Cookie authorization mechanism is that it assumes that their is a single monolithic application server. 🤔

Most modern web applications are distributed across the world with a Load Balancer in front of them to share the load.


One way to solve this problem with maintaining a session ID across distributed application architecture is to use Shared Cache (Redis); a typical use case for Redis cache.


Other alternative approach/implementation is to use Sticky Session pattern, where the Load Balancer remembers which server has the user session and it always redirects requests to the same server from that specific user. Yeah but this is NOT scalable in the case of Microservice Architecture, how is this sticky session shared between the different instances?


Let's see how JWT solves this problem❓

Imagine when a client Authenticates, instead of the server saving this use information in a state and return the SessionId as a token, it returns the user information itself as a token.


Now everytime the client makes a subsequent request, the client sends the whole JSON token with the request saying "This is who I'm, this is my ID, and my Name". This time the server isn't Saving anything. Everytime a request comes in, the server goes let's see who this is? This JWT says this user name is "FOO", and they have successfully authenticated, OK boys let him in. This Token here is NOT an ID, it's a JSON Object which has all the information. This TOKEN is known as JSON token.


And off-course the problem of security is handled here by signing the token handed over each time...


when a user authenticates, the server just doesn't send any JSON object, but rather send something in a special signed format. There is a signature here 🔑 . So when the client, sends the subsequent request, the signed JWT token is sent back to the server. 🔐 The server verifies the signature, and it trusts it ONLY if its valid. ❗ all the information the server needs is right there in the token.


This is what JWT is, Its a way for a client and server to communicate and share information directly that has some meaning across multiple interactions without the server having to remember information for each client. So in the context of Session token/ID, and JSON web token...


Think of Session ID as a Reference token to a state, ✅ JWT is a Value token

How is JWT token sent to client from server

Just like Session ID can be sent using cookie 🍪 , JWT can be sent using cookie 🍪 too 👍

You want to save that receiving JWT token in your browser local storage and later send it to server on your subsequent request? yes you can do that too.

JWT and Session tokens are just different options for what is exchanged, and how you exchange them is up to you.

How does JWT looks like

One might ask, isn't it like painful to send an extra JSON object with every HTTP requests?

It actually doesn't look like a JSON Object.


In fact, you can take this token and figure out what this looks like in JSON in the next section.

JWT Structure

Is nothing but a token with JSON value. It is specifically used for AUTHORIZATION, and NOT for Authentication ⚠️ It only comes into picture when Authentication is completed.

If you look at JWT token sample above, it doesn't look like JSON, but rather looks like a bunch of random characters. However, there're couple of things that you can infer from this toke.

⚠️ Notice, the THREE different colors separated by a DOT are the THREE parts.

  // it tells how this token is signed, also base64 encoded
  "alg": "HS256", // is the type of algorithm used to verify the Signature defined in the last part
  "typ": "JWT" // type of future we might have a another type of token
  // is a data (encoded in base64) that identifies who this user is
  "id": "1234567890", // id of the user 
  "name": "John Doe", // issued to
  "iat": 1516239022 // issued at
  // this is how the signature is calculated 
  //     (header + payload) & sign it your key = signature
  base64UrlEncode(header) + "." + // the base64 Header JSON Object
  base64UrlEncode(payload), // the base64 Payload JSON Object
  your-256-bit-secret // is the consumer secret key which only the Server has. Hence, no one can temper with this token although one might think that Header & Payload is in the open. This is what refers to a **cryptographic** hash.

⚠️ Note: Payload on its own is not sufficient, Header and Signature is what lends the authenticity

Go here to see the THREE parts in action.

Let's understand the flow of this token... jwt-token-flow

  1. User login using userID/password

  2. Server authenticates this user by identifying who this user is

  3. Server generates & signs a JWT token for future authorization purposes, and subsequent interaction

  4. Server sends the JWT token back to client

  5. when client receives JWT token, it can do one of two things...and pass this token on every subsequent request

    i. save in browser local storage 🏬
    ii. save in a cookie 🍪

  6. Client passes this JWT token using HTTP Header { Authorization: Bearer JWT }

  7. Server examine the HTTP header, and verifies the token i. by splitting the token into THREE parts described above HEADER.PAYLOAD.SIGNATURE



  1. How secure is JWT if its readable by anyone? As mentioned before, you don't want to have any confidential/sensitive (SSID, password, NI#) information in JWT. You just need enough info for the server to know who this person is to establish the principal on the server.
  2. What is someone steals my JWT and uses it themselves in a request, they can impersonate as me? Server just verifies if JWT is correct. It doesn't know who sent it. So technically someone can use this token. Hence, its important how you transmitting JWT. Connection between client and server needs to be encrypted (TLS), and it should be used in congestion with OAuth; as it has its own mechanism for Authenticating and Authorizing. To make sure that people don't steal JWT token.
  3. How do you disable a JWT? Possibly a disadvantage of JWT. When compared to Session ID based authentication. Now in the cases of someone stole your Session ID, User can log off and it ends the session ⭐, also session can expire. In the case of JWT, there is nothing on the Server to end this token; the whole information is inside the JWT. You can set up expiration for JWT. Another way a server can invalidate the JWT is to maintain a state of Block Listed JWT tokens, and check the incoming token against his list.

How to implement JWT

click link


Authorization is the process of verifying what you've access to.


Authentication is the process of proving your identity.

There're various type of Authentication, some of which are...

HTTP Basic Authentication

This form of authentication requires that the server request a username and password from the web client and verify that username and password are valid by comparing them against a database of authorized users in the specified or default realm (see Terminology).

When Basic Authentication is declared, the following actions occur:

  1. A client requests access to the protect resource.
  2. The server returns a dialog box that requests the username and password.
  3. The client submits the user name and password to the server.
  4. The server authenticates the user in the specified realm and, if successful, returns the requested resource.


Cons. of Basic Authentication

Basic AuthN is not secure mechanism as it sends creds (u/p) over the Internet as text that is Base64 encoded. If someone can intercept the transmission, the user name and password information can easily be decoded

However, when use in conjunction with TLS, or security at network level such as IPSEC protocol or VPN strategies, some of these can be alleviated (less severe).

Form-Based Authentication

This form of authentication is done through presenting a user with a form (usually a HTML login page) to obtain credentials in order to access a protect resource.

When form-based authentication is declared, the following actions occur:

  1. A client requests access to a protected resource.

  2. If the client is unauthenticated, the server redirects the client to a login page.

  3. The client submits the login form to the server.

  4. The server attempts to authenticate the user.

    a. If authentication succeeds, the authenticated user’s principal is checked to ensure it is in a role that is authorized to access the resource. If the user is authorized, the server redirects the client to the resource using the stored URL path.

    b. If authentication fails, the client is forwarded or redirected to an error page.


Cons. of Form-Based Authentication

Form-Based AuthN is not secure mechanism as the content of the user dialog box is sent as plain text, and the target server is not authenticated. If someone can intercept the transmission, the user name and password information can easily be decoded.

However, when use in conjunction with TLS, or security at network level such as IPSEC protocol or VPN strategies, some of these can be alleviated (less severe).

⚠️ NOTE: When creating a form-based login, be sure to maintain sessions using cookies or SSL session information.

Certificate-Based Authentication

It is the use of digital certificate (Public Key Certificate) to identify a user, machine, or device before granting access to a resource, network, application etc.

Certificate-based Authentication Pros.

🥇 Certificate-based authentication is stronger as compared to password based authentication.

Digital certificates can then be reused for user authentication.

In this form of authentication, certificates are stored on the local machine or device. No additional hardware needed unlike biometric or token based authentication. It not only saves cost, but can also elevate management pains around distributing, replacing and revoking tokens.

Token or biometrics vs Certificate-based Authentication

What is a digital Certificate

Use of Digital Certificate

Public Key Infrastructure (PKI)

PKI is digital certificate management system for distribution, generation, storage, and verification of certificates.

PKI comprise of the following...

How to implement Certificate-Based Authentication

This form of authentication is implemented using HTTPs; which is implementation of TLS.

Transport Layer Security (TLS)

Formerly known as Secure Socket Layer (SSL) is a security protocol designed to facilitate privacy and security for communication over an internet.

TLS can be implemented in 2 forms:

TLS Use Case

Difference between HTTPs and TLS

Why you should use TLS

What does TLS do?

There are three main components to what the TLS protocol accomplishes: Encryption, Authentication, and Integrity.

One-way Authenticated TLS

Let's understand what is one-way authenticated TLS, and how TLS handshake works.

This form of authenticated TLS is when a Client is Thin-Client or some browser accessing a secure website. This way communication between both parties is secure from one side. See Two-way Authenticated TLS for securing communication from both sides.

How TLS handshake works

  1. Client sends ClientHello message to initiates SSL/TLS handshake process by proposing SSL options. tls-handshake-1-way-step-1
  2. Server responds with ServerHello message selecting the SSL options. tls-handshake-1-way-step-2
  3. Server sends Certificate message, which contains the server's certificate. tls-handshake-1-way-step-3

Two-way Authenticated TLS

Let's understand what is two-way authenticated TLS, and how TLS handshake works.

This form of authentication through TLS is between Server:Server/Business:Business for secure communication. This way communication between both parties is secure from both sides. Used when there is an integration between two systems.

How TLS handshake works

In this form of TLS handshake, the server and the client authenticate one another.

  1. A client requests access to a protected resource.
  2. The web server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client sends its certificate to the server.
  5. The server verifies the client’s credentials.
  6. If successful, the server grants access to the protected resource requested by the client.


Detail steps as follows:

In this form of TLS handshake, step 1 - 3 shown in One-way handshake will still happen, but here we introduce step 4 and onward to perform two-way authenticated TLS.

  1. Server requests client's certificate in CertificateRequest message, so that the connection can be mutually authenticated. tls-handshake-2-way-step-4
  2. Server concludes its part of the negotiation with ServerHelloDone message. tls-handshake-2-way-step-5 6.Client responds with Certificate message, which contains the client's certificate. tls-handshake-2-way-step-6
  3. Client sends session key information (encrypted with server's public key) in ClientKeyExchangemessage. tls-handshake-2-way-step-7
  4. Client sends a CertificateVerify message to let the server know it owns the sent certificate. tls-handshake-2-way-step-8
  5. Client sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send. tls-handshake-2-way-step-9
  6. Client sends Finished message to let the server check the newly activated options. tls-handshake-2-way-step-10
  7. Server sends ChangeCipherSpec message to activate the negotiated options for all future messages it will send. tls-handshake-2-way-step-11
  8. Server sends Finished message to let the client check the newly activated options.

Username and Password-Based Mutual Authentication

This form of authentication is used in conjunction with one-way authenticated TLS as an alternative to [two-way/mutual authenticated TLS](#two-way authenticated TLS).

How TLS handshake works

In user name- and password-based mutual authentication, the following actions occur:

  1. A client requests access to a protected resource.
  2. The web server presents its certificate to the client.
  3. The client verifies the server’s certificate.
  4. If successful, the client sends its user name and password to the server, which verifies the client’s credentials.
  5. If the verification is successful, the server grants access to the protected resource requested by the client.


Role Based Access Control (RBAC)

See Azure RBAC