AppAuth-Android: an OAuth 2.0 and OpenID Connect client SDK for Android that refuses to use a WebView

What AppAuth-Android actually takes off your plate

Writing an OAuth 2.0 client by hand on Android means constructing authorization URLs, parsing redirect URIs, validating state, storing refresh tokens and remembering to refresh an access token before each API call. AppAuth-Android covers that surface. It is a client SDK for talking to OAuth 2.0 and OpenID Connect providers, and it deliberately maps the requests and responses of those specifications rather than hiding them behind a simplified login API.

The audience is narrow and specific: Android developers integrating with an authorization server that supports native apps as described in RFC 8252. The README is explicit that servers which assume all clients are web-based, or which require clients to keep a client secret confidential, may not work well. That sentence is the real boundary of the project. If your provider only issues secrets to confidential clients, this SDK is the wrong shape for your problem, no matter how well it is written.

AuthState, AuthorizationService and the browser hop

The design separates state from transport. AuthState encapsulates the authorization state of the user, and the README notes it is designed to be easily persistable as a JSON string using whatever storage you prefer: SharedPreferences, SQLite, or a plain file. AuthorizationService is the class that talks to the authorization server.

Authorization happens in the user's web browser, not inside your app. A request is described with an AuthorizationRequest instance and dispatched with performAuthorizationRequest() on an AuthorizationService; the response arrives as an AuthorizationResponse delivered to an activity of your choice through an Intent. Token operations follow the same pattern: a TokenRequest goes out through performTokenRequest(), and a TokenResponse comes back in a callback. Results are fed into update() methods on AuthState so the state stays current.

The convenience layer sits on top. Once the state is authorized, performActionWithFreshTokens() refreshes access tokens as needed before running an action that requires valid ones. That single method is the reason many teams pick this library over rolling their own token refresh timer.

One architectural decision deserves attention. The library follows RFC 8252 and uses Custom Tabs for authorization requests. WebView is explicitly not supported, for usability and security reasons. That is a hard constraint, not a configuration option, and it will surface immediately if your app has an existing WebView-based login screen.

Installing AppAuth-Android from Maven Central

The artifact lives on Maven Central under the group net.openid. The README gives the dependency line with a version placeholder, so you supply the version you want to track.

implementation 'net.openid:appauth:<version>'

After a Gradle sync, the library classes resolve under the net.openid.appauth package. AppAuth supports Android API 16 (Jellybean) and above. Browsers that provide a Custom Tabs implementation are preferred by the library but not required, and both custom URI schemes (all supported Android versions) and App Links (Android M, API 23 and up) can be used for the redirect.

A first real use is the authorization code flow with a public client, which the README recommends for native apps. It has four stages: discover or specify the provider endpoints, authorize the user in a browser to obtain an authorization code, exchange that code for a refresh token or ID token, then use access tokens derived from the refresh token against a resource server. The repository ships a demo app under app/ with its own readme covering how to build and configure it, and that is the fastest way to see the flow end to end rather than reconstructing it from the Javadoc. The README does not reproduce a full code sample for constructing the AuthorizationRequest, so the demo app and the Javadoc links are where the concrete call sequence lives.

Where the library gets in your way

The spec-faithful data classes are both the selling point and the friction. Because the library models OAuth 2.0 closely to support a wide variety of implementations, you construct requests and interpret responses yourself. There is no login button, no themed account picker, no built-in error UI. If your team expected a drop-in authentication screen, this is not that project.

The WebView exclusion is the second real limitation. Apps that already render login inside a WebView, for reasons like intercepting cookies or controlling the page appearance, cannot migrate by swapping a class. They have to move the flow into Custom Tabs and accept that the browser owns the page.

Redirect handling is a third constraint that bites at integration time. Custom URI schemes work on all supported Android versions, while App Links require Android M or later. You register one or both, and the authorization server has to agree. A mismatch between the redirect URI registered with the provider and the one your app declares produces a failure that looks like a provider problem but is not. The README does not document a rollback or migration path for apps moving off a WebView flow, so plan that transition yourself.

How it differs from a hosted login SDK

The obvious alternative approach is a hosted authentication SDK from an identity vendor, where the vendor's UI handles the browser hop and your app receives a session object. The difference is where the protocol lives. With AppAuth-Android, the request and response objects are yours, the endpoints are yours to discover or specify, and the token refresh is triggered by performActionWithFreshTokens() inside your process. With a hosted SDK, the provider decides which flows are available and how the redirect is shaped, and you trade protocol visibility for less code.

A second alternative is writing the flow against the Android browser APIs directly. That is viable if you only ever talk to one provider with fixed endpoints, but you then own PKCE generation, state validation and refresh logic. AppAuth-Android supports the PKCE extension, which was created to secure authorization codes in public clients when custom URI scheme redirects are used, and it accepts additional parameters in all protocol requests and responses so standard or non-standard extensions can be passed through. Reproducing that flexibility by hand is more work than it looks.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-03-22. The project is licensed under Apache-2.0, which permits commercial use and modification; the LICENSE file sits at the repository root alongside AUTHORS, CONTRIBUTING.md and CONTRIBUTORS. That licence text governs your obligations, and reading it is your call rather than something this article can settle.

Upgrade cost centres on the dependency line. Because the README publishes the coordinate with a placeholder version, you choose how aggressively to move. The API surface is class-based and the README points to Javadoc for net.openid.appauth, so signature changes are visible before you build. There is no separate migration guide in the README, and no recent releases were retrieved, so pin a version you have exercised rather than tracking the newest artifact blindly.

Editorial conclusion

Adopt AppAuth-Android if your authorization server follows RFC 8252 and you want the protocol visible in your own code, with AuthState persisted through SharedPreferences, SQLite or a file of your choosing. Do not adopt it if your provider assumes a confidential web client, or if you expect a drop-in login screen: the library ships protocol objects, not UI. Before wiring it into a release build, verify that your redirect URI is registered for both the custom scheme and the App Links form, and confirm the authorization server accepts PKCE for a public client.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openid/AppAuth-Android on GitHub
4. Project website
5. README