idee

Software Engineer building with Kotlin and Flutter.

Software Engineer at Busha

Idorenyin Obong

We will take a look at some standard practices we should apply when building Android applications.

Best Practices in Android Development

Jose-Romaniello

I started working at Auth0 before the first line of code for our authentication platform existed. I’ve been able to go through the journey of seeing our ideas go from prototype to living production code that impacts millions of people. It’s satisfying to know that my actions here are having a positive impact in solving problems for developers like me.

Head of Engineering

Jose Romaniello

Learn how to apply the Scout code to software development to get code to a better state continuously.

When I was a kid, I practiced [_Scouting_](https://en.wikipedia.org/wiki/Scouting) for eight years I picked up a lot of excellent values and my scouting experiences helped to shape my character and make me a better programmer. Let me show you why.

As a Scout, you get to experience nature by camping outdoors which teaches you one of the core values — **respect life**. Scout rules help support core Scout values. One of the first rules I learned was:

> Always leave the campground cleaner than you found it.

This rule comes from a quote by [_Robert Baden-Powell_](https://en.wikipedia.org/wiki/Robert_Baden-Powell,_1st_Baron_Baden-Powell), founder and first [_Chief Scout_](<https://en.wikipedia.org/wiki/Chief_Scout_(The_Scout_Association)>) of [_The Scouts Association_](https://en.wikipedia.org/wiki/The_Scout_Association), and founder of the [_Girl Guides_](https://en.wikipedia.org/wiki/Girlguiding):

> Leave this world a little better than you found it.

What this rule represents is that you should not only pick up your trash, clean the area where you started a wood fire and the soil where you built your tent, but also you need to take a look at the campsite and do something to leave it better than it was before.

It is an explicit instruction. It helps you accept the notion that something can always be better. There’s always room for improvement. You had the opportunity to enjoy the area and its resources but you also have the opportunity to pay back by leaving the area in better shape for others.

I believe that when kids are taught this kind of values through games, repetition, and rewards, it becomes a habit. This is nominally known as [_positive reinforcement_](https://en.wikipedia.org/wiki/Reinforcement#Positive_reinforcement). Positive reinforcement takes place when a reward is presented as the result of certain behavior and the behavior increases. This trait has been embedded in my mind so that I don’t need to apply it consciously. It has become a behavioral reflex that integrates naturally in my day-to-day activities.

## The Codebase Is the Developer's Campsite

Even if I don't go camping often nowadays, I follow this rule in a lot of different situations in my life. One of them is in my daily work — programming!

Working on a new feature or a bug feels excellent. Working on a codebase change feels like camping as a Scout. It is an opportunity to:

- Experience the environment.
- Understand the problem.
- Put what I know in practice.
- Use my skills to create solutions.

The codebase will host me for hours or days. Even if I don't enjoy the codebase too much, I still have to respect it because other people have worked hard on it. It gives me an opportunity to learn new things and to possibly use tools I have never been exposed to before.

<include src="TweetQuote" quoteText="Even if we don't enjoy a codebase too much, we still have to respect it because other people have worked hard on it. We can work on taking little steps to improve it."/>

Once again, I have to assume that other people will get to "camp" in the project after me. People I haven't met yet and probably will never meet. They may be developers, project managers, even end-users. As thought leader and software craftsman [_Uncle Bob Martin_](https://twitter.com/unclebobmartin) says in his [_Scout Rule_](https://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484):

> “Indeed, the act of leaving a mess in the code should be as socially unacceptable as littering. It should be something that just isn't done.”

Therefore, not only my work in the codebase needs to be clean, but it should leave the code at least a little better than I found it.

These are some examples in which I have applied this improvement of the status quo within a project:

- It took me 30 minutes to understand what this function does. Can I rename it to something more declarative or expressive so that others can understand it quicker than I did?
- I wasn't able to run this project with the provided instructions. Can I write the instructions that I followed but are not documented in a README file?
- This code is more convoluted than it should be. Can I make it easier and clearer?
- This function doesn’t have enough tests. Can I add some tests?

These small improvements will help my teammates and myself later. The code is not going to end up perfect, but it will be better than it was before. By following this practice, the code grows in a better direction with every action that you take on it.

<include src="TweetQuote" quoteText="Small but powerful actions for teams that improve a codebase gradually: Vague naming? Make it explicit. Confusing code? Make it clearer. No documentation? Add steps to the README. Missing tests? Write one."/>

I have been doing software development for years and being a Scout had already prepared me to transfer the mindset and values exposed by Uncle Bob from the campsite to the codebase. But this approach is not an excuse for not allocating exclusive time and developers to fix issues in a codebase; it is just one way to continuously get things to a better state.

![Binary tree - example of clean code growing organically and gradually following the Scout development approach.](https://images.ctfassets.net/23aumh6u8s0i/5KLuJlW0dEoHg3Wf03i7t9/a11e8be6f2480802675a8d4daaf6c3c2/Binary-Tree)

<include src="asides/AboutAuth0" />

A Scout Approach to Software Development

eHk3ciM

I am the Group Manager, Developer Content at Okta, and a Google Developer Expert in Web Technologies and Angular. I'm passionate about identity, authentication, constant learning, and developer communities. As a developer advocate, engineer, mentor, and international speaker, I love learning from and sharing with other inhabitants of the tech space.

Group Manager, Developer Content

Kim Maida

Learn why universal login is the most secure, standards-based strategy when authenticating with a provider.

**TL;DR:** To maintain a successful application, you will inevitably need a universal account system, as opposed to embedding login within your application. Universal login is more secure, standards-based, maintainable, and future proof. This is where the industry is moving, and in this post, we will explore this trend.

---

## Introduction

High standards of security and ease of use have been set for modern authentication platforms and APIs. Users expect seamless logins that work across apps and entities without requiring them to log in over and over on the same device. Companies and developers expect robust security for their data and top-notch protection for their customers, preferably without incurring intensive implementation or maintenance overhead.

### What is Universal Login?

**Universal login** refers to a [method of login hosted by the authentication provider](https://auth0.com/docs/hosted-pages/login) for your app or site. A link or button in your app triggers an authentication request and users are then presented with a login experience provided by the authentication provider. Because authentication is taking place on the same domain as the login, credentials are not sent across origins. Universal login is the most _secure_ way to authenticate users, as well as the most _standards-based_. We'll cover <a href="#why-use-universal-login" target="_self">how and why</a> in much more detail below.

### What is Embedded Login?

**Embedded login** refers to a method of authentication wherein credentials are entered via an experience that is _embedded_ on an app's domain with text inputs and are then sent to an authentication provider for verification and login. This is a _cross-origin_ request. Embedded logins present a range of potential security and implementation challenges that cause issues for developers and users; as a matter of fact, [Google no longer supports an embedded approach when implementing OAuth](https://auth0.com/blog/google-blocks-oauth-requests-from-embedded-browsers/).

### What Do Universal and Embedded Login Look Like?

![Universal vs. embedded login](https://images.ctfassets.net/23aumh6u8s0i/5lXoFh88lNEZ41N8NOORYA/35ade19a2e6603719c1338329b948174/centralized-embedded-diagram)

1. **Universal Login** - When clicking a button or link to authenticate in both the browser and native app, the universal login URL at [accounts.google.com](https://accounts.google.com) is loaded.
2. **Embedded Login** - When clicking a button or link to authenticate in the browser, an overlay modal is opened on the same domain, prompting the user to log in. The mobile app also displays input fields within the app.

## Why Universal Login is a Long-Term Investment

Let's look at a hypothetical example using a timeline from an imaginary company. Let's say our make-believe company, "SourceCentral", provides public and private source control repository hosting. Their timeline looks something like this:

![Hypothetical timeline for a service switching to universal login](https://images.ctfassets.net/23aumh6u8s0i/6wzVEf7a5UREYmGYdQ5yZl/d9a04c1906342c8ad2cb5035228fddce/timeline2)

* **Year 0: Launch!** We launched a source control repository hosting service. Our homegrown authentication is working out alright for our needs since we are still small and only have one service.
* **Year 1: Going native** Lots of people have signed up and outlook is great! People love our service. We are launching native Android and iOS mobile apps as well as desktop apps for Windows and MacOS, and we need to implement login for all of them.
* **Year 1.5: APIs** We're now developing an API so that we can better serve our customer base of developers who want to be able to integrate our service with third parties, but...
* **Year 2: Auth for third parties** Authentication has been a huge challenge now that we have an API that requires authorization as well as several apps and third-party integrations. 😧 To address the complexities and issues this is presenting, we're implementing OAuth in order to provide a much more _universal_ authentication and authorization process for our product and APIs.
* **Year 3: SSO** With a universal login approach, we're now able to leverage Single Sign-On. Our customers love this. This was easy with a universal login; instead of having to change every single service, we only had to do it once! It's much easier to maintain and enhance.
* **Year 4: Multi-factor Authentication** Our users demand more security, so we're adding Multi-factor Authentication. We can do this for all our apps at once using universal login!
* **Years 5, 6, etc: Growing and scaling!** We're rolling out new properties and apps at a steady pace. We have a desktop app, a community, chat hosting for repositories, and several other services as well. Securing and authenticating all our new services is a non-issue with universal authentication! 🎉

This is a hypothetical timeline, but many companies have undergone very similar processes over the years, including (in case you haven't already guessed!) [GitHub](https://github.com). Implementing universal login is a long-term investment. Doing so _early_ paves the way for growth, development, maintainability, and new feature integration far into the future.

<include src="TweetQuote" quoteText="Universal login is a long-term investment. Implementing early paves the way for growth and new feature integration far into the future."/>

## Why Universal Login is Best Practice

Universal login has many advantages over an embedded login approach, including better security, single sign-on benefits, simpler maintainability, modern user experience, and more. Let's explore these in more detail.

<include src="TweetQuote" quoteText="Universal login provides security, SSO, maintainability, best practice native app implementation, and more."/>

### Security

Universal login is more secure than embedded login. Authentication takes place over the same domain, eliminating cross-origin requests. Cross-origin authentication is inherently more dangerous. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities. [Phishing attacks](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/) are more likely, as are [bucket brigade attacks](https://auth0.com/docs/security/common-threats#man-in-the-middle-mitm-attacks), also known as man-in-the-middle (MITM) attacks. Universal login does not send information between origins, thereby negating cross-origin concerns.

Embedded user agents are unsafe for third parties, including the authorization server itself. If an embedded login is used, the app has access to both the authorization grant and the user's authentication credentials. As a consequence, this data is left vulnerable to recording or malicious use. Even if the app is trusted, allowing it to access the authorization grant as well as the user's _full_ credentials is unnecessary. This violates the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) and increases the potential for attack.

### Single Sign-On

Universal login orchestrates [single sign-on](https://auth0.com/docs/sso/current) (SSO) between multiple apps while providing cookies from the same origin. Once a user has logged in using a universal login, a cookie is created and stored. Any future calls to the authentication provider's authorization endpoint will then check the cookie. If the user has already signed on, the login page will not be shown again and the user will be logged in via SSO. On the other hand, embedded user agents don't share authentication state, meaning that they cannot be used for SSO.

![universal login with Google](https://images.ctfassets.net/23aumh6u8s0i/1YugCWp0Ra98EeeupBfBqN/7fadfd6f1334f1d3dfb5a5a17cd21a0d/google-login)

### Easier to Implement and Maintain

Universal login is easier to implement as well as maintain for app developers. Cross-origin authentication is inherently more dangerous, but universal login mitigates this risk entirely. Developers do not need to manage the dangers of cross-origin attack vectors if they use universal login instead of embedded login. A universal login page is also already fully implemented, negating the need for the developer to build out their own embedded login UI. The authorization server providing the universal login page can also ensure a consistent and secure experience across all apps that utilize it.

### Best Practice on Native Mobile

The [OAuth 2.0 Best Current Practice for Native Apps RFC](https://www.rfc-editor.org/rfc/rfc8252.txt) requires that _only_ external user agents, such as universal login, should be used for authenticating with OAuth 2.0 in native mobile applications. This is considered best practice for reasons cited above, including security and single sign-on. You can [read more about the OAuth 2.0 BCP for Native Apps here](https://auth0.com/blog/oauth-2-best-practices-for-native-apps/).

![Google login on mobile app](https://images.ctfassets.net/23aumh6u8s0i/3ahqZk6Umj456bBK6MR0en/0b2e534235a83ddbfafcc7ce3b1bab93/google-login-mobile)

 

Native mobile apps that use OAuth 2.0 (such as Gmail, YouTube, and others) use the device browser as an external user agent for universal login.

### User Experience

Modern users are comfortable with signing in at the authorization provider's universal login page to authenticate (e.g., OAuth with Google, Facebook, GitHub, etc.), in turn gaining the benefits of single sign-on and not being required to repeatedly log into other apps on the same device as long as they are using the same authentication provider.

![universal login with Facebook](https://images.ctfassets.net/23aumh6u8s0i/213AnVULw3nratInY7hOx4/0bb7f7764843aea22f4777c8ba38e55c/facebook-login)

These login pages are on the authorization provider's domain. However, most people don't even notice the redirect because the modern flow of universal login functions so seamlessly. After signing in, they're brought back to the application and are now authenticated. The user experience of universal login is easy and natural, and is the standard expectation for users of modern web and mobile apps. In addition to being more secure, it provides transparency. In doing so, the user is assured that they are securely logging in with a trusted and familiar entity.

![universal login with GitHub](https://images.ctfassets.net/23aumh6u8s0i/51Aq6EuG8BElVcD2RL14W2/aebce1638b1fce4f73a11dadd77349a4/github-login)

## Conclusion

Universal login is the most secure and maintainable standards-based approach to logging in with an authentication provider. Unlike embedded login, it is safer from cross-origin attack vectors and poses no danger to the authorization server. Universal login is the [best current practice for native mobile apps](https://auth0.com/blog/oauth-2-best-practices-for-native-apps/), and OAuth providers like [Google no longer support embedded login strategies](https://auth0.com/blog/google-blocks-oauth-requests-from-embedded-browsers/). It also provides a comfortable and consistent user experience that confers the benefits of SSO.

<include src="TweetQuote" quoteText="Universal login is safer from cross-origin attack vectors and poses no danger to the authorization server."/>

In keeping with app modernization and current best practices, [Auth0](https://auth0.com) provides a robust [universal login](https://auth0.com/docs/hosted-pages/login) solution with integrations for dozens of [social identity providers](https://auth0.com/docs/identityproviders#social), [enterprise identity providers](https://auth0.com/docs/identityproviders#enterprise), custom [OAuth 2.0 integrations](https://auth0.com/docs/protocols/oauth2), [username/password databases](https://auth0.com/docs/connections#database-and-custom-connections), features like [passwordless authentication](https://auth0.com/passwordless) (with SMS or email), and more.

With Auth0, the universal login page is a [fully customizable UI](https://auth0.com/docs/hosted-pages/login#3-customization). In addition, Auth0's [CNAME](https://en.wikipedia.org/wiki/CNAME_record) functionality to persist the same domain across the universal login page and the app is scheduled to launch before the end of 2017.

![Auth0 universal login page](https://images.ctfassets.net/23aumh6u8s0i/6TwsXjuNeMnkg5I4ZN3y5o/c4b1c77a6e5b8e10b44dc000bde49d19/auth0-centralized-login)

You can <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a> to try out these features and more to modernize your app's authentication and follow standards-based best practices.

Authentication Provider Best Practices: Universal Login

The IETF has released Best Current Practice (BCP) for OAuth 2.0 in native apps. Learn about it now.

**TL;DR:** In October, 2017, the [Internet Engineering Task Force (IETF)](https://www.ietf.org/) released the [Best Current Practices (BCP) when using OAuth 2.0 with native mobile applications](https://www.rfc-editor.org/rfc/rfc8252.txt). This BCP states that OAuth 2.0 authorization requests from native apps should _only_ be made through external user agents, primarily the user's browser. We'll discuss what this means for developers and users and any security considerations involved.

---

## OAuth 2.0 Best Current Practice for Native Apps

The IETF ([Internet Engineering Task Force](https://www.ietf.org/)) recently released the [Best Current Practice for OAuth 2.0 for Native Apps Request For Comments](https://www.rfc-editor.org/rfc/rfc8252.txt). This document requires that, in accordance with best practices, only external user agents (such as the browser) should be used with the [OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749) by native applications; this is known as the "AppAuth pattern". Embedded user agents should not be implemented.

> _For authorizing users in native apps, the best current practice is to perform the OAuth authorization request in an external user agent (typically the browser) rather than an embedded user agent (such as one implemented with web-views)._
>
> -_[OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt)_

Using the browser to make native app authorization requests results in better security. It also enables use of the user's current authentication state, making single sign-on possible. Embedded user agents are unsafe for third parties. If used, the app has access to the OAuth authorization grant as well as the user's credentials, leaving this data vulnerable to recording or malicious use. Embedded user agents also don't share authentication state, meaning no single sign-on benefits can be conferred.

We'll go into the security and implementation advantages of using the browser for authorization requests in more detail below.

<include src="TweetQuote" quoteText="Using the browser to make native app authorization requests results in better security."/>

### Authorization Flow for Native Apps Using the Browser

The authorization flow for native apps using the browser acts as illustrated in the following diagram:

![Authorization flow for OAuth 2.0 in native apps using the browser](https://images.ctfassets.net/23aumh6u8s0i/3ULKZFPLQiGXHa9NFNCpCS/bd5c463c34ae60a1aee86af0db199b3a/hoauth-flow)

> 1. Client app opens a browser tab with the authorization request.
2. Authorization endpoint receives the authorization request, authenticates the user, and obtains authorization. Authenticating the user may involve chaining to other authentication systems.
3. Authorization server issues an authorization code to the redirect URI.
4. Client receives the authorization code from the redirect URI.
5. Client app presents the authorization code at the token endpoint.
6. Token endpoint validates the authorization code and issues the tokens requested.
>
> _Figure 1, [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt)_

URIs are used for OAuth 2.0 on the web for authorization requests and responses. Similarly, URIs can also be used in native apps. When the built-in browser is employed by the user for all native app logins, certain advantages are conferred, such as the ability to use a single sign-on session stored in a central location and additional security afforded by an authentication context that is separated from the app. Browser security is also a major focus of vendors, and they tend to manage security and sessions policies quite well. In addition, supporting and implementing the same approach in web and native apps reduces complexity and increases interoperability.

<include src="TweetQuote" quoteText="Implementing external user agents in both web & native apps reduces complexity and increases interop."/>

### Initiating and Receiving Authorization Requests

Native apps now must request user authorization by creating a URI with the appropriate [grant type specified in the OAuth 2.0 Authorization Framework](https://tools.ietf.org/html/rfc6749#section-4.1). The app then redirects the user to this request URI. A redirect URI that the native app can receive and parse appropriately must also be supplied. This must be implemented using an _external user agent_. Use of the device browser is recommended.

The authorization server must permit at least three redirect URI options for the response sent back to the native app:

* Private-Use URI Scheme Redirection
* Claimed "https" Scheme URI Redirection
* Loopback Interface Redirection

You can read about these three options in detail in Section 7 of [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt).

## OAuth 2.0 Security Considerations for Native Apps

When implementing OAuth 2.0, there are a number of security considerations that developers must be mindful of when using best current practice with an external user agent. We'll go over a few of them now.

### Authorization Code and Grant Flow

Using the redirect options above means that the authorization code can only be received by native apps on the same device. While this increases security, it does still mean that another app on the same device could potentially intercept the code. The [Proof Key for Code Exchange (PKCE) protocol](https://tools.ietf.org/html/rfc7636) was created to defend against this attack vector. Public apps as well as servers _must_ use PKCE, and servers should reject authorization requests from apps that do not.

It is _not_ recommended to implement [implicit grant flow](https://auth0.com/docs/api-auth/grant/implicit) in native apps because this flow cannot be protected by PKCE. Instead, [authorization code grant flow with PKCE](https://auth0.com/docs/api-auth/grant/authorization-code-pkce) should be used.

### Authorization Servers and Clients

In most cases, native apps are considered public clients and must be registered with the authorization server. Authorization servers must also register a client's complete redirect URI. If an authorization request does not match the registered redirect URI, the request must be rejected.

User authentication and consent will be required by the authorization server, as per any other web browser based OAuth 2.0 flows.

### User Agents

Embedded user agents should not be used to masquerade as an external user agent. Authorization servers can protect against these fake agents by requiring an authentication factor only available to genuine external user agents.

Cross-Site Request Forgery (CSRF) attacks should also be mitigated by using the `state` parameter to link client requests and responses. More details are available in section 5.3.5 of [OAuth 2.0 Threat Model and Security Considerations](https://tools.ietf.org/html/rfc6819).

The user's browser is the recommended external user agent. Embedded user agents must not be used for authorization requests. Authorization servers may detect and block requests from embedded user agents, as they are unsafe for third parties, such as the authorization server itself. The reason for this is because the app can then access not only the OAuth authorization grant, but also the user's full authentication credentials. The app could then potentially record or use this information maliciously. In addition, embedded user agents don't share authentication state with other apps or the browser and therefore disabling single sign-on benefits.

## Conclusion

If you're a native app developer, it's very important to adhere to best current practices. Please take the time to read over the [OAuth 2.0 for Native Apps](https://www.rfc-editor.org/rfc/rfc8252.txt) RFC yourself. Using an external user agent for OAuth 2.0 authorization requests provides better security as well as an improved user experience as it enables [single sign-on](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/) across the device's apps and browser.

### Centralized Login with Auth0

[Auth0](https://auth0.com) provides a [centralized login approach](https://auth0.com/docs/hosted-pages/login) that adheres to the OAuth 2.0 Best Current Practice for native apps. Centralized login provides the most secure experience and is also easy to implement for developers. A URI is used to trigger an authentication request and the centralized login page is shown to users. This login page can use the [Auth0 Lock widget](https://auth0.com/lock) or your own custom UI. After authorization, the user is returned to your app via your provided redirect. Auth0 provides extensive documentation to help you easily implement the appropriate flows to keep your apps secure and user-friendly as well.

Check out the following resources to learn more about implementing Auth0 with centralized login in your native apps in accordance with the OAuth 2.0 Best Current Practice:

* [Centralized Login Page](https://auth0.com/docs/hosted-pages/login)
* [OAuth 2.0](https://auth0.com/docs/protocols/oauth2)
* [Calling APIs from Mobile Apps (Authorization Code PKCE)](https://auth0.com/docs/api-auth/grant/authorization-code-pkce)
* [iOS Swift Quickstart - Login](https://auth0.com/docs/quickstart/native/ios-swift/00-login)
* [Android Quickstart - Login](https://auth0.com/docs/quickstart/native/android/00-login)

You can sign up for a <a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">free Auth0 account now</a> and get started right away, or check out [Auth0's pricing here](https://auth0.com/pricing).

"best-practices"