Authentication Provider Best Practices: Centralized Login

To maintain a successful application, you will inevitably need a centralized account system, as opposed to embedding login within your application. Centralized 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 Centralized Login?

Centralized login refers to a method of login hosted by the authentication provider 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. Centralized login is the most secure way to authenticate users, as well as the most standards-based. We'll cover how and why 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 in an app's domain with text inputs and is then sent to an authentication provider for verification and log in. 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.

What Do Centralized and Embedded Login Look Like?

1. Centralized Login - When clicking a button or link to authenticate in both the browser and native app, the centralized login URL at 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 Centralized 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:

• 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 the 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 centralized authentication and authorization process for our product and APIs.
• Year 3: SSO With a centralized login approach, we're now able to leverage Single Sign-On. Our customers love this. This was easy with a centralized 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 centralized 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 centralized 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. Implementing centralized login is a long-term investment. Doing so early paves the way for growth, development, maintainability, and new feature integration far into the future.

Why Centralized Login Is a Best Practice

Centralized 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.

Security

Centralized 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 are more likely, as are man-in-the-middle attacks. Centralized 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 and increases the potential for attack.

Single Sign-On

Centralized login orchestrates single sign-on (SSO) between multiple apps while providing cookies from the same origin. Once a user has logged in using a centralized 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.

Easier to Implement and Maintain

Centralized login is easier to implement as well as maintain for app developers. Cross-origin authentication is inherently more dangerous, but centralized login mitigates this risk entirely. Developers do not need to manage the dangers of cross-origin attack vectors if they use centralized login instead of embedded login. A centralized 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 centralized 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 requires that only external user agents, such as centralized 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.

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

User Experience

Modern users are comfortable with signing in at the authorization provider's centralized 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.

These login pages are on the authorization provider's domain. However, most people don't even notice the redirect because the modern flow of centralized login functions so seamlessly. After signing in, they're brought back to the application and are now authenticated. The user experience of centralized 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.

Conclusion

Centralized 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. Centralized login is the best current practice for native mobile apps, and OAuth providers like Google no longer support embedded login strategies. It also provides a comfortable and consistent user experience that confers the benefits of SSO.