Introduction

Authorization refers to the process of granting or denying access to a fully authenticated entity — whether it is a human user, a background service, or an application — for a specific set of resources or actions within a system. While authentication answers the fundamental question of "Who are you?", authorization answers the subsequent question of "What are you allowed to do?".

In modern architectures, authorization is often managed through access tokens that represent the permissions granted to a client application. These tokens are issued by an authorization server and act as a structured or cryptographic proof of a specific, limited grant of authority. This is achieved by evaluating roles, permissions, and operational contexts before a resource server permits data retrieval or modification. To formalize this mechanism, the OAuth 2.0 Authorization Framework (RFC 6749), decouples the management of permissions from the application logic itself.

The architecture defined by RFC 6749 breaks down the authorization ecosystem into four distinct, interacting roles:

• Resource Owner: The entity capable of granting access to a protected resource, typically an end-user.
• Resource Server: The infrastructure hosting the protected data or services, capable of accepting and validating access tokens to respond to protected resource requests.
• Client: An application making protected resource requests on behalf of the resource owner and with its authorization.
• Authorization Server: The engine that authenticates the resource owner, obtains authorization, and issues access tokens to the client.

Mekarge A3, as the Authorization Server, keeps the vocabulary as is in its core implementation.

A first-party application is an application that is developed and maintained by the same organization that provides the service or resource being accessed. Unlike third-party applications, which are developed by external entities, first-party applications have direct access to the service provider's infrastructure and data. Examples include an official mobile banking application communicating with the bank's internal API services, or a proprietary web dashboard created by a company for its internal employees to manage customer records.

However, even though first-party applications are developed within the same organization, they are not immune to security threats. First-party applications often require more granular control over access, as the service provider can implement more stringent security policies and audit controls. Treating first-party applications as formal OAuth 2.0 clients improves security and operational consistency. Each application receives explicitly scoped access tokens, and access can be revoked independently if a device or application instance becomes compromised. This model also aligns with Zero Trust principles by ensuring that every request is authenticated and audited consistently across the organization. Furthermore, it allows internal development teams to utilize uniform API gateways and standardized validation libraries across all backend microservices, regardless of whether the inbound request originates from an internal tool or an external partner.

Mekarge A3 is built to address all security needs of first-party applications.

OAuth 2.0 addresses several key challenges related to delegated access, secure API authorization, and token-based application security. OAuth 2.0 is based on completely decoupling authentication from authorization through a token-based paradigm. Instead of handling or storing passwords, first-party applications use standardized workflows to obtain short-lived, cryptographically secure access tokens. The client application never handles the raw password long-term; it merely passes an access token to the backend APIs.

This architecture resolves three critical operational problems:

• Scalability: Internal services no longer need to know how the user authenticated; they simply validate the digital signature of the inbound access token. This allows engineering teams to build, deploy, and scale microservices independently.
• Fine-Grained Authorization: OAuth 2.0 introduces Scopes, which act as fine-grained, explicit permissions attached directly to the token. Even if an application is compromised, the attacker is strictly confined to the limited scopes embedded within that specific token, preventing lateral movement across the rest of the enterprise infrastructure.

By standardizing both human-to-machine and machine-to-machine authorization under a single token-based framework, OAuth 2.0 establishes a uniform, auditable, and resilient security posture across the entire first-party application ecosystem.

Identity management is the process of identifying, authenticating, and authorizing individuals or entities within a system. It ensures that the right users have access to the right resources at the right time, while maintaining the integrity, confidentiality, and availability of information.

Identity management systems typically include mechanisms for user registration, authentication, and authorization. These processes are governed by standards including OAuth 2.0 and OpenID Connect, which provide a secure and scalable framework for managing digital identities.

For first-party applications, centralized identity management is critical. It provides a consistent user experience across a suite of products while keeping sensitive credential verification logic separated from the core business logic of individual applications. As security architectures have evolved toward Zero Trust models, identity has emerged as the new perimeter. In a Zero Trust environment, network locality is no longer trusted implicitly; instead, every access request must be explicitly authenticated and authorized based on a dynamic assessment of identity, device health, and contextual telemetry.

OpenID Connect (OIDC) is an identity layer built directly on top of the OAuth 2.0 framework, specifically defined in the OpenID Connect Core 1.0 specification. While OAuth 2.0 was originally designed strictly as an authorization framework to grant applications limited access to resources, it lacked a native mechanism for transmitting identity information. OpenID Connect fills that gap by extending OAuth 2.0 with a standardized, identity layer that provides verifiable user information to the client applications.

The core addition of OpenID Connect is the introduction of the ID Token. This ID Token contains essential information about the user, such as their unique identifier, the time of authentication, and other properties.

OAuth 2.1 consolidates security best practices from the OAuth 2.0 Security Best Current Practice and formalizes the deprecation of insecure behaviors.

OAuth 2.1 specification recommends practices to mitigate known attack vectors. Chief among these architectural refinements is the strict enforcement of the Authorization Code Flow combined with Proof Key for Code Exchange (PKCE), originally defined in RFC 7636. This setup ensures that even if an authorization code is intercepted on a user's device, it cannot be exchanged for a token by a malicious actor. Furthermore, OAuth 2.1 emphasizes the elimination of static client secrets for public clients, such as mobile or single-page web applications, as these environments cannot securely store credentials.