OAuth 2.0 is an authorization framework, it provides an interface for third-party applications to obtain access to protected HTTP resources.
The OAuth 2.0 framework is divided into 4 main pieces, as follows,
- Resource Owner, where we have users. They are unique identified by their login;
- Client Apps, are the application itself. They are identified by their unique client Id.
- Resource Server has endpoints protected that may only be accessed after successfully validating the token provided by the Client App against the Authorization Server;
- Authorization Server holds the logic to generate and validate tokens based on the Resource Owner and Client Apps.
OAuth2 Scopes
Scopes are used to limit the Resource Server's access to information by the User. Client Apps may request access to a wide type of scopes in order to perform its operation whereas the user has to consent or not.
As an example of using scopes, we have mobile applications that ask consent to have access to different resources on our phone, like the contact list, camera, audio, etc.. Each one of those resources is a scope.
OAuth2 Client Types
OAuth 2.0 supports two types of client types according to their capability to store credentials securely which will impact directly on how they can read the token, as follows,
- Confidential Client can store credentials securely. The token can be read Symmetrically with the client secret or Asymmetrically with a private key.
- Public Client, can not store credentials securely. The token can be read Asymmetrically with a private key or with the public key used to sign the private key.
OAuth2 Grant Types
OAuth 2.0 has a wide range of grant types available as far as the possibility to create custom ones but their most used grant types are as follows,
- Authorization Code is the most used grant type whereas public and confidential clients exchange the authorization code for an access token.
- Client Credentials, when the app sends its own credentials (client id and client secret) in order to obtain an access token.
- Device Code, used by devices to exchange a previously obtained device code for an access token;
- Refresh Token, used when the token is expired so the client exchanges the refresh token for a brand new token without any interaction with the user.
OAuth2 Bearer Token
The Bearer token is the most used type of token used with OAuth 2.0. It is composed of the word Bearer followed by the token, this token may range from hexadecimal string to more structured types of tokens.
Example of usage,
- Authorization: Bearer eyJhbGciOiJSUzI1NiIsastpZCI6IkM3MDQ2QjI0Mzc4RTJCNjYwMjI1MzFCNTcwQjY5NDNEREYyOEMwRDAiLCJ0eXAiOiJKV1QiLCJ4NXQiOiJ4d1JySkRlT0syWUNKVEcxY0xhVVBkOG93TkEifQ.eyJuYmsYiOjE2MDIyNTU1NDcsImV4cCI6MTYwMjI2OTk0NywiaXNzIjoiaHR0cHM6Ly9hdXRoLmFcuZXBlcmYuY29tIiwiYXVkIjpbImh0dHBzOi8vYXV0aC5hbmVwZXJmLmNvbS9yZXNvdXJjZXMiLCJld3BlbmV0d29ya2FwaSIsImV3cG
Microsoft Identity Platform
Microsoft Identity Platform works as an Authorization Server but is much stronger than any normal Authorization Server because it has other functionalities such as passwordless authentication, step-up authentication, and conditional access.
Microsoft Identity Platform offers an interface to manage authorization among Azure resources, being capable of assigning resources to access other resources without explicitly doing an authorization request.
It is built by several components in order to achieve its so powerful engine as follows,
- OAuth2.0 for authorizations;
- OpenId Connect for authentications;
- Microsoft Authentication Library ( MSAL ) for authenticating users against the Microsoft Identity platform;
- Azure Portal to manage and configure your applications, authorizations, and authentications;
What are Shared Access Signatures - SAS?
Shared Access Signatures handles authorization and authentication, they are tokens generated with very specific purposes to access resources, those tokens may have limitations such as which resource it may access, which operations (read, write, delete) may be executed and during which time range it can be used. Shared Access Signatures are grouped in 3 different types as follows,
- User delegation SAS applied for Blob Storages only and combines the security of the Azure AD with the permissions from the SAS;
- Service SAS, applied at Blob storage level, Queue storage level, Table storage level, or Azure Files level. Can be assigned with a Stored Access Policy;
- Account SAS applied at the Storage Account level and can not be used with a Stored Access Policy;
Stored Access Policy with SAS
Stored Access Policies are policies, on the container level, associated with one or more SAS which defines constraints for those associated SAS.
It is a good practice to associate SAS with Stored Access Policy because when a SAS is associated with a Stored Access Policy this SAS inherits all the constraints from the Stored Access Policy, and if you need to revoke access for this SAS you only need to terminate the access from the Stored Access Policy instead of needing to generate a new storage account key. By generating a new storage account key you would have to update your clients to use the new key in order to access its resources.
Those constraints are the ones as follows,
- Start time, the date that the Stored Access Policy will start to be valid. SAS associated with this Stored Access Policy can not be used before the start time.
- End time, the date that the Stored Access Policy will expire. Those SAS associated with this Stored Access Policies is going to expire together.
- Permissions, the resources, and operations that this Stored Access Policy will be able to manipulate.
What are Role-Based Access Controls (RBAC)?
Azure Role-Based Access Controls is another security functionality that helps how you manage access through your resources. It handles users' authorization, managing who has access to each resource, and what each user can do with each resource.
In order to understand better how to Azure Role-Based Access Controls works let's go through its key concepts, as follows,
- Security Principal, an object that represents a user, group, service principal, or managed identity who is request access to an Azure resource. Roles are assigned to Security Principals;
- Role Definition, collection of permissions with a list of operations that may be executed by each permission;
- Scope, holding access for each role. Scopes can be configured at a management group, subscription, resource group, or resource levels;
- Role Assignment, which is the process of assigning a role to a security principal;
- Multiple Assignments happens when you have more than one role assigned to the same security principal to the same resource. When it happens, Azure sums the roles without impact any of them;
- Deny Assignment, is the opposite of the Role Assignment whereas we specify a set of actions that are denied.
To organize those roles, Azure distributes the managing among some types of custom roles and pre-created roles, the pre-created roles are the ones as follows,
- Subscription Administrator Roles, having full access to the subscription account and is grouped in 3 subcategories as follows
- Account Administrator, 1 per Azure Account and manages mainly the billing;
- Service Administrator, 1 per Azure Subscription and manages the services in the Azure Portal;
- Co-Administrator, 200 per subscription and has the same privileges as the Service Administrator;
- Azure Roles, providing access management to Azure resources. Some resources have their specific roles but there are some fundamental roles applied to all resources as follows:
- Owner, full access to all resources and can delegate access to others;
- Contributor, full access to all resources;
- Reader, reading resources but not being able to update/delete/create it;
- User Access Administrator, managing users' access to Azure resources;
- Azure AD Roles used to manage Azure AD resources and is grouped in 3 main categories as follows:
- Global Administrator manages access to Azure AD Resources and assign the User Administrator role to others;
- User Administrator manages access to users and groups. Also, manages tickets and health;
- Billing Administrator, managing the billing of the account;
What is Azure AD?
Azure Active Directory is Microsoft's cloud-based identity that handles Authorization and Authentication for internal(Azure, Microsoft 365, etc..) and external resources (your company intranet, corporate network, etc..), one of its main features is to access a wide range of Applications and Systems within a Single Sign-On.
Within Azure AD you can manage all your users and apps in a single location, which means that your users may change from one app to another without needing to log in again, without risking security. Actually, your security is going through a big boost as far as your users will not need to store and input different usernames and passwords when they are accessing different apps, and Azure AD also offers multi-factor authentication, which will be helping you and your organization with governance and a higher layer of security.
In order to understand better about Azure AD, we are going through a brief explanation of its main terminologies as follows,
- Identity could be a user, an application, or even another server that needs to get authenticated;
- Account, an identity with related data;
- Azure AD Account, an identity created through Azure AD or another Microsoft cloud service;
- Azure Tenant represents a single organization inside Azure AD;
- Single Tenant APPs, apps that belong to a single Azure Tenant;
- Multi-Tenant APPs, apps that belong to more than one Azure Tenant;
- Azure AD directory, the dedicated Azure AD directory owned by the tenant. It has users, groups, and apps;
- Custom Domain, domains now owned by Microsoft;
- MSA, the Microsoft Account (Outlook, Xbox Live, Office 365 accounts) ;
Practical Examples
OAuth2 Authentication