Open Authorization 2.0 (OAuth2.0) - Authorization Code Grant

Chethan K — Thu, 18 Jul 2024 14:00:27 +0000

Let's Consider there is an image generator-based application that generates images based on text input and finally it should be saved in some storage provider ex Google Drive. but the image generator application can't access the drive to store the image, it's not safe to provide a username and password to any third-party applications like the one above. OAuth 2.0 helps in solving the above problem.

Open Authorization 2.0 is the authorization framework that enables third-party applications to obtain limited access to an HTTP Service.
it may be on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its behalf.

Grant types in OAuth 2.0

Authorization Code Grant
Client Credentials Grant
Implicit Grant
Resource Owner Password Grant
Device Authorization Grant

Now, we will discuss the most famous Grant type Authorization code Grant flow

taking the above example will explain each step involved in the Authorization code grant type

First of all, for third-party (Client) applications to make use of OAuth, they need to be registered with the Authorization Server and get the client ID and secret.

First, the user (Resource Owner) accesses the third-party application (Client) in our example its image generator, which will generate images based on his input. now he wants to save it to some storage say Google Storage.
now the application redirects in the browser with the client ID, redirect URI, response types ex code, and scopes.
once the authorization server/resource server gets the request authorization server will prompt for user login if there is no active session for logging in to the authorization resource/server in our case, the Google Authorization Server.
once the user logs in, the authorization server presents a consent form based on scopes requested by the client, for example writing blob to storage, reading blobs, etc.
once the scopes are granted by the resource owner, the authorization server will redirect back to the client using the redirect uri sent by the client during the initial request with the authorization code.
once the client gets the authorization code it sends the client ID and secret along with the authorization code.
once the authorization server gets client credentials along with the authorization code it responds with the access token.

now the client will use that access token with limited privileges based on scopes It is able to access resources/execute a particular task, in our case saving the image as a blob to Google storage/Drive using google API.

Multitenant Considerations In Azure

Chethan K — Thu, 06 Jun 2024 19:37:04 +0000

What is Multitenancy?

A multitenant solution serves multiple distint customers or tenants and they might be individual organizations or group of users.Examples include B2B solutions (like accounting software), B2C solutions (such as music streaming), and enterprise-wide platforms (like shared Kubernetes clusters).

a multitenant solution is mostly considered by those who building SaaS products.who mainly targeted for business or consumers.

Design Considerations for Multitenant Solution

Tenant Isolation

One of the biggest considerations in the design of a multitenant architecture is the level of isolation that each tenant needs. Isolation can mean different things:

Having a single shared infrastructure, with separate instances of your application and separate databases for each tenant.
Sharing some common resources, but keeping other resources separate for each tenant.
Keeping data on a separate physical infrastructure. In the cloud, this configuration might require separate Azure resources for each tenant. It could even mean deploying a separate physical infrastructure by using dedicated hosts.

Tenancy Models

1. Automated single-tenant deployments

In an automated single-tenant deployment model, you deploy a dedicated set of infrastructure for each tenant.

people who use this model use infrastructure as code (IaC) for repeating the infra creation and deployment for all customers and hence automate it.
A key benefit of this approach is that data for each tenant is isolated, which reduces the risk of accidental leakage.
cost efficiency is low, because you don't share infrastructure among your tenants. If a single tenant requires a certain infrastructure cost, 100 tenants probably require 100 times that cost.

2. Fully multitenant deployments

In this approach unlike single-tenant deployment here all components are shared. we will have only once set of infrastructure to deploy and maintain.

operating this model is less expensive as components are shared accross tenants.even if we want to deploy with higher tiers or SKUs of resources still the overal deployment cost is lower the cost of single-tenant resources.
Might have risk of memory leaks and down time affects all the tenants

3. Automated single-tenant deployments

This approach has combination of single-tenant and multitenant deployments. For example, you might have most of your customers' data and application tiers on multitenant infrastructures, but deploy single-tenant infrastructures for customers who require higher performance or data isolation.

Deploy multiple instances of your solution geographically, and map each tenant to a specific deployment. This approach is particularly effective when you have tenants in different geographies.

Since you're still sharing infrastructure, you can gain some of the cost benefits of using shared multitenant deployments. But codebase will probably need to be designed to support both multitenant and single-tenant deployments.

4. Horizontally partitioned deployments

In a horizontal deployment, you have some shared components but maintain other components with single-tenant deployments. For example, you could build a single application tier and then deploy individual databases for each tenant.

Horizontally partitioned deployments can help you mitigate a noisy neighbor problem, if you identify that most of the load on your system is caused by specific components that you can deploy separately for each tenant.
With a horizontally partitioned deployment, you still need to consider the automated deployment and management of your components, especially the components used by a single tenant.

Ref-https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/overview

DEV Community: Chethan K