OAuth 2.0: What It Is and How the Authorization Protocol Works

What Is OAuth 2.0?

OAuth 2.0 is an authorization protocol defined in IETF RFC 6749 that allows third-party applications to obtain limited access to a user’s resources without revealing their username and password. The protocol solves a fundamental problem with the password model: an application you trust with your password gains unrestricted access to all account data. OAuth 2.0 replaces this approach by issuing a temporary token with an explicitly limited access scope.

The architecture of OAuth 2.0 is delegated authorization. The user (Resource Owner) authorizes an application (Client) to access their data stored on a resource server (Resource Server) through an intermediary — the authorization server (Authorization Server). The authorization server issues an Access Token — a cryptographic string that the application presents to the resource server to access data. An important distinction between OAuth 2.0 and SAML or OpenID Connect: OAuth 2.0 addresses the authorization task (what is allowed), not authentication (who the user is). The OpenID Connect (OIDC) protocol is built on top of OAuth 2.0 for authentication.

The protocol is supported by all major platforms. Google uses OAuth 2.0 for accessing Google APIs (Gmail, Drive, Calendar), Facebook for Graph API, Apple for Sign in with Apple (ASAuthorizationAppleIDProvider), and GitHub for repository access. In the context of mobile development, OAuth 2.0 is the standard mechanism for integrating third-party services: social media login, cloud storage access, and content publishing on behalf of the user.

OAuth 2.0 Roles and Components

The OAuth 2.0 protocol defines four roles whose interaction forms the complete authorization cycle. Understanding each role is essential for correctly implementing the protocol in a mobile application.

The Four Protocol Roles

The key protocol entities are the Access Token, Refresh Token, and Authorization Code. The Access Token is a short-lived token (usually 15–60 minutes) presented to the resource server with each data request. The Refresh Token is a long-lived token (days or weeks) used to obtain a new Access Token without requiring the user to log in again. The Authorization Code is a temporary code issued after user authorization and exchanged for an Access Token and Refresh Token.

Grant Types: Authorization Scenarios

OAuth 2.0 defines several Grant Types — token acquisition scenarios, each designed for a specific type of client and security context. Choosing the right Grant Type is a critical architectural decision when designing authorization in a mobile application.

The main Grant Types are: Authorization Code (the most secure for mobile and web applications with a server component), Authorization Code with PKCE (Proof Key for Code Exchange — for mobile and SPA applications without a server backend), Client Credentials (for server-to-server authentication without user involvement), and Resource Owner Password Credentials (deprecated — transmits the password directly). PKCE is a mandatory extension for public clients (mobile applications, SPAs) according to the OAuth Security BCP (RFC 9700) recommendations.

Main Grant Types

• Authorization Code + PKCE — the recommended Grant Type for native mobile applications. The client generates a cryptographic code_verifier, computes a code_challenge (SHA-256 hash), and the server verifies the match when exchanging the code for a token. This prevents authorization code interception between the application and the server
• Client Credentials — used for machine-to-machine authorization where the client is known and authenticated. The application obtains a token using its client_id and client_secret. No user involvement is required. Typical scenario: a server application calls an API for batch data processing
• Device Authorization Grant — for devices without a browser (Smart TV, IoT). The user follows a link on another device and enters a code. Used, for example, when authorizing Netflix on a TV via a smartphone
• Resource Owner Password Credentials — a deprecated Grant Type prohibited by OAuth Security BCP. The password is transmitted directly to the client, violating the zero-knowledge authentication principle. Only used for migration from legacy systems

Authorization Code Flow with PKCE for Mobile Applications

Authorization Code Flow with PKCE is the recommended OAuth 2.0 configuration for native mobile applications. PKCE (Proof Key for Code Exchange) adds an additional layer of protection, preventing authorization code interception attacks. The protocol is described in IETF RFC 7636.

PKCE Step-by-Step Sequence

The sequence of steps: (1) the client generates a random code_verifier (a 43–128 character string using only unreserved characters), (2) the client computes code_challenge = SHA-256(code_verifier), (3) the client opens a browser for user authorization on the Authorization Server, passing the code_challenge, (4) after successful authorization, the server returns the authorization code to the application via a custom URI scheme (app deep link), (5) the client sends the authorization code + code_verifier to the server, (6) the server verifies SHA-256(code_verifier) === code_challenge and issues an Access Token + Refresh Token.

The advantage of PKCE is that even if an attacker intercepts the authorization code in the URI scheme, they cannot exchange it for a token without the code_verifier, which is known only to the legitimate client. In mobile applications, you should use Chrome Custom Tabs (Android) or ASWebAuthenticationSession (iOS) to open the browser — this ensures the system browser cannot access the code_verifier from the application’s memory.

Implementing OAuth 2.0 on Android via AppAuth

AppAuth is the reference implementation of OAuth 2.0 and OpenID Connect for native applications, recommended by the IETF. The library supports PKCE, Chrome Custom Tabs, custom URI schemes for returning the authorization code, and automatic token refresh. AppAuth for Android is available via the `net.openid:appauth:0.11.1` dependency.

val serviceConfig = AuthorizationServiceConfiguration.fromUrl(
    Uri.parse("https://accounts.google.com/.well-known/openid-configuration")
)

val request = AuthorizationRequest.Builder(
    serviceConfig,
    "CLIENT_ID.apps.googleusercontent.com",
    ResponseTypeValues.CODE,
    Uri.parse("com.example.app:/oauth2callback")
)
.setScope("openid profile email")
.setCodeVerifier(
    CodeVerifierUtil.generateRandomCodeVerifier()
)
.build()

val authService = AuthorizationService(context)
val intent = authService.getAuthorizationRequestIntent(request)

// Launching Chrome Custom Tab for authorization
startActivityForResult(intent, REQUEST_CODE_AUTH)

After receiving the authorization code (onActivityResult), the application exchanges it for an Access Token and Refresh Token via a TokenRequest. Tokens are saved in SharedPreferences with encryption using EncryptedSharedPreferences (Android Security Crypto). The Refresh Token should be stored in the KeyStore — a hardware-backed key store inaccessible to other applications. Each time the Access Token expires, the application uses the Refresh Token to obtain a new one — the user does not need to re-authenticate.

// Exchanging authorization code for tokens
val data = intent?.data ?: return
val resp = AuthorizationResponse.fromIntent(data)
val exchangeReq = resp?.createTokenExchangeRequest()
    ?: return

authService.performTokenRequest(
    exchangeReq,
    ClientAuthentication.none()
) { tokenResp, ex ->
    if (tokenResp != null) {
        // Access Token and Refresh Token received
        val accessToken = tokenResp.accessToken
        val refreshToken = tokenResp.refreshToken
        // Save to EncryptedSharedPreferences
        saveTokens(accessToken, refreshToken)
    }
}

The code above demonstrates the complete OAuth 2.0 PKCE flow: creating a server configuration via OpenID Connect Discovery, generating an authorization request with a code_verifier, launching a Chrome Custom Tab, receiving the authorization code via a custom URI scheme, and exchanging the code for tokens via a Token Request. It is important to handle Access Token expiration: when receiving an HTTP 401 response from the Resource Server, the application should use the Refresh Token to obtain a new Access Token and retry the request.

OAuth 2.0 Security: Common Attacks and Protection

OAuth 2.0 is a complex protocol with many attack vectors. The IETF Security BCP (RFC 9700) describes over 20 classes of OAuth 2.0 vulnerabilities. For mobile applications, the most critical are: authorization code interception via custom URI schemes, CSRF attacks on callback endpoints, Refresh Token theft from insecure storage, and client impersonation through intent interception.

Protection against these attacks includes mandatory measures: (1) PKCE with S256 code_challenge — prevents authorization code interception even if the URI scheme is intercepted; (2) use of a nonce or state parameter to prevent CSRF — the server verifies that the authorization code matches the original request; (3) storing the Refresh Token only in the KeyStore (Android) or Keychain (iOS) — never in SharedPreferences or UserDefaults; (4) using TLS with Certificate Pinning to protect against MITM at the transport layer; (5) validating redirect_uri — the authorization server must strictly validate it against the registered URI.

Additional recommendations from the IETF: mobile applications should use AppAuth or similar libraries that have undergone security audits; do not rely on WebView for OAuth (WebView does not isolate data from the main application); implement automatic Refresh Token rotation (each Refresh Token can be used only once); add Certificate Pinning via the TrustManager for Android and URLSession for iOS. OpenID Connect Discovery (well-known endpoint) helps automatically determine the correct authorization server endpoints and avoid redirects to phishing pages.