In today's fast-paced mobile landscape, swift app development and secure user authentication are crucial for hybrid apps built with Cordova. OAuth 2.0 is the gold standard for authorization, but traditional flows often rely on a client secret – a sensitive credential that can be impractical to store securely in mobile apps. As public clients, mobile apps can't safeguard secrets from reverse engineering or tampering.

This article demystifies how Cordova apps using the Microsoft Active Directory Authentication Library (ADAL) plugin leverage the OAuth 2.0 Authorization Code Grant flow without a client secret to authenticate users with Azure Active Directory (Azure AD). We'll break down the flow, walk through setup steps, and provide code examples to implement this in your Cordova app.

Understanding Swift App Development: OAuth 2.0 Authorization Code Grant

OAuth 2.0 is an authorization framework that enables third-party apps to access resources on behalf of a user without exposing their credentials. The Authorization Code Grant is the most secure and widely used flow, designed for server-side (confidential) clients. Let's contrast the standard flow with the public client variant.

Standard Flow with Client Secret

In the standard flow (for confidential clients like web apps), the client uses a client secret to authenticate itself when exchanging an authorization code for tokens. Here's a simplified breakdown:

  • User Initiates Login: The app redirects the user to the identity provider (e.g., Azure AD) with a client_id, redirect_uri, and scope.
  • User Authenticates: The user logs in, and Azure AD returns an authorization code to the app's redirect_uri.
  • Exchange Code for Tokens: The app sends the code, client_id, and redirect_uri to Azure AD's token endpoint.
  • Tokens Issued: Azure AD validates the client_secret and returns an access_token (to access resources) and refresh_token (to get new tokens).

Public Clients: Why Client Secrets Are a Problem

Mobile apps (Cordova, iOS, Android) and desktop apps are public clients – they cannot securely store a client_secret. If embedded in the app, the secret can be extracted via reverse engineering, enabling attackers to impersonate the app.

To address this, OAuth 2.0 allows public clients to omit the client_secret during token exchange. Instead, the flow relies on:

  • Redirect URI Validation: Azure AD ensures the redirect_uri matches the one registered for the app.
  • PKCE (Proof Key for Code Exchange): A security layer to prevent authorization code interception attacks (required for public clients in modern flows like OAuth 2.1).

Cordova, ADAL, and Azure AD: The Stack Explained

What is Cordova?

Apache Cordova (formerly PhoneGap) is an open-source framework for building hybrid mobile apps using web technologies (HTML, CSS, JavaScript). It wraps web code in a native container, enabling deployment to iOS, Android, and other platforms.

Microsoft ADAL Plugin: Role and Limitations

The Microsoft ADAL (Active Directory Authentication Library) Cordova Plugin simplifies authenticating users with Azure AD in Cordova apps. It handles:

  • Redirecting users to Azure AD for login.
  • Securely storing tokens (access, refresh) on the device.
  • Automatically refreshing tokens.

Note: ADAL is deprecated. Microsoft recommends migrating to MSAL (Microsoft Authentication Library), which supports modern flows (e.g., PKCE) and better security. This blog focuses on ADAL for legacy use cases but emphasizes MSAL as the future-proof alternative.

How the Secret-Less Authorization Code Grant Works

For Cordova apps using ADAL and Azure AD, the secret-less Authorization Code Grant flow works as follows:

Key Adjustments for Public Clients

  • No Client Secret: The app omits the client_secret when exchanging the authorization code for tokens.
  • Redirect URI Enforcement: Azure AD validates that the redirect_uri in the token request matches the one registered for the app (prevents malicious apps from intercepting codes).
  • PKCE (Implicit in ADAL?): ADAL may use PKCE under the hood to secure the code exchange, though explicit support varies by version. PKCE adds a cryptographic challenge to ensure only the original app can exchange the code for tokens.

Step-by-Step Flow for Cordova + ADAL + Azure AD

  • App Initializes Auth: The Cordova app uses ADAL to trigger a login flow, specifying client_id, redirect_uri, and resource (e.g., Microsoft Graph API).
  • User Redirected to Azure AD: ADAL opens a system browser (not an in-app webview) to Azure AD's login endpoint. The user authenticates (enters username/password, MFA).
  • Authorization Code Issued: Upon success, Azure AD redirects the user back to the app's redirect_uri with an authorization code.
  • ADAL Exchanges Code for Tokens: ADAL sends the code, client_id, redirect_uri, and (optionally) a PKCE verifier to Azure AD's token endpoint. No client_secret is sent.
  • Tokens Returned: Azure AD validates the request (via redirect_uri and PKCE) and returns access_token, refresh_token, and id_token.
  • Tokens Stored Securely: ADAL stores tokens in the device's secure storage (e.g., Keychain for iOS, Keystore for Android).
  • Access Resources: The app uses the access_token to call APIs (e.g., https://graph.microsoft.com/v1.0/me).
  • Token Refresh: When the access_token expires, ADAL uses the refresh_token to silently fetch a new one (no user interaction).

Setup: Register Your App in Azure AD

Before coding, register your Cordova app in Azure AD to enable authentication.

Prerequisites

  1. Create an Azure AD tenant.
  2. Register your Cordova app as a native client application.
  3. Configure the redirect URI for your app.

By following this guide and leveraging the Microsoft Active Directory Authentication Library (ADAL) plugin, you can efficiently implement the OAuth 2.0 Authorization Code Grant flow without a client secret in your Cordova app.