The benefits of APIs are becoming more clear in an ever-evolving tech landscape, yet ITDMs still struggle to convince executives and investors to buy into an API-first strategy. Here’s a look at the importance of APIs in a changing world, and how ITDMs can make the business case in order to secure the best API strategy for their organization.

According to Google Cloud’s new “State of the API Economy 2021” report, a majority of IT decision-makers view application programming interfaces, or APIs, as essential ingredients in improved customers experiences, expanded partner engagement, accelerated innovation, and other demands of today’s business environment. This is encouraging: APIs are how software talks to other software, and since much of digital transformation involves combining disparate data and functionality into rich user experiences and process automations, APIs are an essential ingredient in modern business strategies. 

What’s less encouraging: the research surveys primarily IT professionals, not business leaders. It’s clear that IT people see the benefits of APIs in the ever-changing tech landscape, but we still hear regular concerns from these same people that they have trouble convincing executives and investors to buy into an API-first strategy. In this article, we’ll look into why they are having these difficulties and some proven ways to successfully position an API strategy not just as a technological solution, but also as a business requirement.

The importance of APIs in a changing world

The rise of APIs has been heavily influenced by the introduction of disruptive new business models and evolving customer preferences that traditional technologies are not positioned to quickly and efficiently address. 

For example, traditionally, if your business sold tickets to events, it would build physical ticket booths and maybe a website or first-party mobile app. Today, tickets in many cases aren’t so much a physical thing presented to an usher as a digital code that an usher scans. Likewise, tickets are less-often purchased in person as opposed to online, and reliance on a first-party website can be unnecessarily restrictive. It places the burden on the business to attract customers, whereas surfacing organically in social media, search engine results, and other digital experiences lets the business meet customers where they’re already assembled. 

Moreover, as COVID-19 continues to disrupt events throughout the world, many ticket sellers—and most organizations, for that matter—have pivoted to digital-first business interactions as a matter of necessity. All of these changes in the business model, and all of the interacting systems and functionality that underpin them, rely on communication among APIs. 

Similarly, today’s banks cannot grow by simply building more branches or hiring more tellers. Instead, they need to make financial information and functionality available when and where customers require it, whether that means via an ATM, a first-party app, or within some other digital experience. Many banks also need to do more than just present this functionality, as customers are increasingly interested in the analytics and insights their spending patterns can yield. Again, all of these interactions—from customers making a purchase within an app to banks applying machine learning in order to offer customers financial insights—are enabled by APIs.     

Related: The “State of API Economy 2021” report describes how digital transformation initiatives evolved throughout 2020, as well as where they’re headed in the years to come. Download for free.

When guidance meets resistance

These examples do not illustrate technology that updates the status quo, but rather technology that unlocks business opportunities that transcend the status quo—and that help businesses to thrive even as the status quo fades into irrelevance and obsolescence. APIs are thus not just an IT topic but also important business enablers that should be understood by everyone involved with the enterprise’s investments, from internal stakeholders approving business strategies to external shareholders trying to assess an organization’s trajectory. 

The challenge for investor relations is to convey these financial and operational benefits in a way that clearly communicates the need for a new business model rather than refinements to the existing models. It’s essential that IT professionals understand APIs, but it’s also essential for business leaders to understand them too.

This is even trickier given that arguments for API investments are often based on future potential, while arguments for more conservative alternatives are based on past success. 

At a high level, the API value proposition is clear: In the past, valuable functionality and data have been encased in systems and applications, making them difficult to scale or leverage for new, evolving use cases. In contrast, APIs make functionality and data infinitely reusable, infinitely scalable, and modular such that APIs can easily be combined for new uses. All of this accrues to richer user experiences and more flexibility than ever for companies to monetize their digital assets, share them with partners, or combine them with assets from third parties. 

It’s essential that IT professionals understand APIs, but it’s also essential for business leaders to understand them too.

But investors typically want as much information as possible because their decisions can affect not just productivity and output, but company stock prices and potential future growth. High-level arguments may not be persuasive. The deeper assurances investors crave would normally come from guidance.

Guidance in this context refers to insights based on growth forecasts and customer adoption, but this can be difficult early in market entry. Robust forecasting processes need to be developed to demonstrate the efficacy and value of the API economy, which can be hard to predict: whereas APIs are well understood in some sectors, and especially among digital natives, they are in the early stages of the growth rate in other verticals, making it challenging to forecast developer adoption of a given API. And since there is a shortage of information, trying to use traditional guidance comes with a risk of being wrong and thus of little value to investors.

Related: Set your 2021 API resolutions with these top 2020 posts.

How to deliver a more useful value proposition

While guidance may be premature during the early stages of market entry, investor relations teams still need to convey the full value of an enterprise to investors. To do this, they need a value proposition that emphasizes the intrinsic value of the investment while reinforcing the benefits that can best drive business and stock growth. Considering how large an investment of time, effort, and money transitioning to an API economy can be, it is vital to convey that the benefits are substantial.

A solid value proposition should demonstrate maximum returns, and while this shouldn’t include far-fetched or unobtainable claims, it can include reasonable aspirational visions alongside statistical insights. To craft these aspirational narratives, investor relations teams should look to their organization’s existing business needs and challenges, and then demonstrate how APIs can benefit the organization in these areas. Here are some options that speak to a number of common business requirements:

• Sales channel: API investments are reusable, improve speed to market, enable automated processes and partner onboarding, and can uncover unanticipated opportunities.
• Cost: Businesses can reduce operational costs by using and reusing APIs for innovation and business development, and by using the services native to your partner’s digital surface, you can further reduce innovation costs and risks.
• Earnings: API-enabled digital ecosystems unlock a variety of partner services that leverage the business’s shared data to drive new customer acquisition, new market positions, new transaction volumes, and direct API monetization.
• Risk mitigation: By investing in a credible API, businesses can mitigate downside risks that traditional enterprises can face from market disruptors, industry-wide shifts to digital tools, and inabilities to ingest and analyze growing data sources.
• Intellectual property: Unlike project-driven innovation and customized, point-to-point integration that traps enterprise knowledge in small teams and divisional silos, APIs are reusable and modular, breaking down silos and encouraging intra-organizational collaboration.
• Speed to market: The efficient, repeatable API interface informs improvements to the fulfillment process with consistent access to data from across the organization, which drives solutions that more quickly and efficiently meet customer needs.
• Ethics: APIs offer the flexibility and economical advantages that give organizations the capacity to focus on their brand’s ethical “reason for being” beyond profitability by serving economically marginal and underserved market segments.
• Customer credibility: Organizations can deliver the extended, connected digital experiences that customers expect with the tools and flexibility included with API products.
• Employee retention: Businesses can avoid losing key employees by updating their legacy technologies with APIs, giving employees the opportunity to enhance their skills with modern technologies.
• Corporate strategy: Enterprises that use APIs’ reusable, modular structure and tools are more capable of adapting to rapid structural shifts in customer demand patterns and sectoral changes in the economy.

Whichever of these business challenges a team speaks to, it is imperative that they demonstrate the benefits of APIs, and that once they’ve determined the angle they intend to use, they keep their message consistent. While we’ve seen a number of viable ways to position APIs as a winning strategy, switching among them could make the presentation—and APIs in general—seem insubstantial and unreliable. 

This is why it’s key to decide on the most relevant business concerns, and once you’ve tailored your presentation, to make sure that you have message alignment, including buy-in and support from C-level executives. With a strong pitch built around solving existing business concerns and solidarity from relevant stakeholders, you can go into your investor meeting with the confidence to secure the best API strategy for your organization.

Strengthen your pitch with additional insights. Here are five key trends in 2021 for API-first digital transformation.

About the Author: Paul Rohan is a researcher on Open Banking and a Google Cloud solutions consultant. Paul works with banking C-Suites that are examining the impact of the Platform Economy and Digital Ecosystems on financial services industry growth, market structures and governance. Paul is the author of “PSD2 in Plain English” and “Open Banking Strategy Formation”.

Editor’s note: Today’s post documents the solution to a problem of how to scale website infrastructure as it moves from on-prem to the cloud. It is the result of collaboration between technical teams of Les Echos Le Parisien Annonces (a division of Groupe Les Echos, subsidiary company of LVMH) and Google in the spirit of finding the best tool for the job together.

All technology starts aging from the first day you set it up, and over time becomes in need of some renewal. At Les Echos Le Parisien Annonces (a division of Groupe Les Echos, subsidiary company of LVMH), we complement the main site (“publication annonce légale”) with a number of local market sites for different regions within metropolitan France, as well as French readers in territories across the world. Each local market site offers a variety of services and content, which are served by a set of CMS-driven sites.

Historically these sites were served from dedicated on-prem infrastructure. As the number of sites grew, vertical scaling was used to increase the capacity of the machine. Over time, this approach presented challenges. First, each new site involved modifying multiple shared configurations, and modifying several monolithic parts of the architecture. Because all the sites shared parts of the serving stack, an issue that developed for one site could take down all of the sites. The reliability of the serving path was not able to reach the availability we and our customers expected. Les Echos and Google put their heads together to solve this with a new serverless deployment pattern where each new site can be quickly and independently launched.

Each site, running a conventional PHP CMS solution, is now containerized and deployed as its own Cloud Run service with an independent configuration and database. This means each site scales vertically, including down to zero at times of day when that locale is quiet. Because Cloud Run is available across GCP regions, we can deploy sites closest to the market we want to reach. To further enhance our customer experience, each of these sites is run behind Cloud Global Load Balancing with Cloud Armor and Cloud CDN, providing extra security and performance. The initial pilot of 30 sites has performed well, and the remainder of the 150 current sites are now being migrated. Adding new sites has gone from taking hours to minutes. This allows Les Echos to quickly explore new opportunities in markets that previously would have taken much longer to assess and qualify for investing in a new site.

Adopting this serverless approach has been a successful step in the modernization journey to Google Cloud, allowing us to use containers to take existing software and both re-architect and re-platform to support growth while reducing toil.

Updated for 2021: This post includes updated best practices including the latest from Google’s Best Practices for Password Management whitepapers for both users and system designers.

Account management, authentication and password management can be tricky. Often, account management is a dark corner that isn’t a top priority for developers or product managers. The resulting experience often falls short of what some of your users would expect for data security and user experience.

Fortunately, Google Cloud brings several tools to help you make good decisions around the creation, secure handling and authentication of user accounts (in this context, anyone who identifies themselves to your system—customers or internal users). Whether you’re responsible for a website hosted in Google Kubernetes Engine, an API on Apigee, an app using Firebase, or other service with authenticated users, this post lays out the best practices to follow to ensure you have a safe, scalable, usable account authentication system.

1. Hash those passwords

My most important rule for account management is to safely store sensitive user information, including their password. You must treat this data as sacred and handle it appropriately.

Do not store plaintext passwords under any circumstances. Your service should instead store a cryptographically strong hash of the password that cannot be reversed—created with Argon2id, or Scrypt. The hash should be salted with a value unique to that specific login credential. Do not use deprecated hashing technologies such as MD5, SHA1 and under no circumstances should you use reversible encryption or try to invent your own hashing algorithm. Use a pepper that is not stored in the database to further protect the data in case of a breach. Consider the advantages of iteratively re-hashing the password multiple times.

Design your system assuming it will be compromised eventually. Ask yourself “If my database were exfiltrated today, would my users’ safety and security be in peril on my service or other services they use?” As well as “What can we do to mitigate the potential for damage in the event of a leak?”

Another point: If you could possibly produce a user’s password in plaintext at any time outside of immediately after them providing it to you, there’s a problem with your implementation.

If your system requires detection of near-duplicate passwords, such as changing “Password” to “pAssword1”, save the hashes of common variants you wish to ban with all letters normalized and converted to lowercase. This can be done when a password is created or upon successful login for pre-existing accounts. When the user creates a new password, generate the same type of variants and compare the hashes to those from the previous passwords. Use the same level of hashing security as with the actual password. 

2. Allow for third-party identity providers if possible

Third-party identity providers enable you to rely on a trusted external service to authenticate a user’s identity. Google, Facebook, and Twitter are commonly used providers.

You can implement external identity providers alongside your existing internal authentication system using a platform such as Identity Platform. There are a number of benefits that come with Identity Platform, including simpler administration, a smaller attack surface, and a multi-platform SDK. We’ll touch on more benefits throughout this list.

3. Separate the concept of user identity and user account

Your users are not an email address. They’re not a phone number. They’re not even a unique username. Any of these authentication factors should be mutable without changing the content or personally identifiable information (PII) in the account. Your users are the multi-dimensional culmination of their unique, personalized data and experience within your service, not the sum of their credentials. A well-designed user management system has low coupling and high cohesion between different parts of a user’s profile.

Keeping the concepts of user account and credentials separate will greatly simplify the process of implementing third-party identity providers, allowing users to change their username, and linking multiple identities to a single user account. In practical terms, it may be helpful to have an abstract internal global identifier for every user and associate their profile and one or more sets of authentication datavia that ID as opposed to piling it all in a single record.

4. Allow multiple identities to link to a single user account

A user who authenticates to your service using their username and password one week might choose Google Sign-In the next without understanding that this could create a duplicate account. Similarly, a user may have very good reason to link multiple email addresses to your service. If you’ve properly separated user identity and authentication, it will be a simple process to link several authentication methods to a single user.

Your backend will need to account for the possibility that a user gets part or all the way through the signup process before they realize they’re using a new third-party identity not linked to their existing account in your system. This is most simply achieved by asking the user to provide a common identifying detail, such as email address, phone, or username. If that data matches an existing user in your system, require them to also authenticate with a known identity provider and link the new ID to their existing account.

5. Don’t block long or complex passwords

NIST publishes guidelines on password complexity and strength. Since you are (or will be very soon) using a strong cryptographic hash for password storage, a lot of problems are solved for you. Hashes will always produce a fixed-length output no matter the input length, so your users should be able to use passwords as long as they like. If you must cap password length, do so based on the limits of your infrastructure; often this is a matter of memory usage (memory used per login operation * potential concurrent logins per machine), or more likely—the maximum POST size allowable by your servers. We’re talking numbers from hundreds of KB to over 1MB. Seriously. Your application should already be hardened to prevent abuse from large inputs. This doesn’t create new opportunities for abuse if you employ controls to prevent credential stuffing and hash the input as soon as possible to free up memory.

Your hashed passwords will likely already consist of a small set of ASCII characters. If not, you can easily convert a binary hash to Base64. With that in mind, you should allow your users to use literally any characters they wish in their password. If someone wants a password made of Klingon, Emoji, and ASCII art with whitespace on both ends, you should have no technical reason to deny them. Just make sure to perform Unicode normalization to ensure cross-platform compatibility. See our system designers whitepaper (PDF) for more information on Unicode and supported characters in passwords.

Any user attempting to use an extreme password is probably following password best practices (PDF) including using a password manager, which allows the entry of complex passwords even on limited mobile device keyboards. If a user can input the string in the first place (i.e., the HTML specification for password input disallows line feed and carriage return), the password should be acceptable.

6. Don’t impose unreasonable rules for usernames

It’s not unreasonable for a site or service to require usernames longer than two or three characters, block hidden characters, and prevent whitespace at the beginning and end of a username. However, some sites go overboard with requirements such as a minimum length of eight characters or by blocking any characters outside of 7-bit ASCII letters and numbers.

A site with tight restrictions on usernames may offer some shortcuts to developers, but it does so at the expense of users and extreme cases will deter some users.

There are some cases where the best approach is to assign usernames. If that’s the case for your service, ensure the assigned username is user-friendly insofar as they need to recall and communicate it. Alphanumeric generated IDs should avoid visually ambiguous symbols such as “Il1O0.” You’re also advised to perform a dictionary scan on any randomly generated string to ensure there are no unintended messages embedded in the username. These same guidelines apply to auto-generated passwords.

7. Validate the user’s identity

If you ask a user for contact information, you should validate that contact as soon as possible. Send a validation code or link to the email address or phone number. Otherwise, users may make a typo in their contact info and then spend considerable time using your service only to find there is no account matching their info the next time they attempt login. These accounts are often orphaned and unrecoverable without manual intervention. Worse still, the contact info may belong to someone else, handing full control of the account to a third party.

8. Allow users to change their username

It’s surprisingly common in legacy systems or any platform that provides email accounts not to allow users to change their username. There are very good reasons not to automatically release usernames for reuse, but long-term users of your system will eventually come up with significant reasons to use a different username and they likely won’t want to create a new account.

You can honor your users’ desire to change their usernames by allowing aliases and letting your users choose the primary alias. You can apply any business rules you need on top of this functionality. Some orgs might limit the number of username changes per year or prevent a user from displaying or being contacted via anything but their primary username. Email address providers are advised to never re-issue email addresses, but they could alias an old email address to a new one. A progressive email address provider might even allow users to bring their own domain name and have any address they wish.

If you are working with a legacy architecture, this best practice can be very difficult to meet. Even companies like Google have technical hurdles that make this more difficult than it would seem. When designing new systems, make every effort to separate the concept of user identity and user account and allow multiple identities to link to a single user account and this will be a much smaller problem. Whether you are working on existing or greenfield code, choose the right rules for your organization with an emphasis on allowing your users to grow and change over time.

9. Let your users delete their accounts

A surprising number of services have no self-service means for a user to delete their account and associated PII. Depending on the nature of your service, this may or may not include public content they created such as posts and uploads. There are a number of good reasons for a user to close an account permanently and delete all their PII . These concerns need to be balanced against your user experience, security, and compliance needs. Many if not most systems operate under some sort of regulatory control (such as PCI or GDPR), which provides specific guidelines on data retention for at least some user data. A common solution to avoid compliance concerns and limit data breach potential is to let users schedule their account for automatic future deletion.

In some circumstances, you may be legally required to comply with a user’s request to delete their PII in a timely manner. You also greatly increase your exposure in the event of a data breach where the data from “closed” accounts is leaked.

10. Make a conscious decision on session length

An often overlooked aspect of security and authentication is session length. Google puts a lot of effort into ensuring users are who they say they are and will double-check based on certain events or behaviors. Users can take steps to increase their security even further.

Your service may have good reason to keep a session open indefinitely for non-critical analytics purposes, but there should be thresholds after which you ask for password, 2nd factor, or other user verification.

Consider how long a user should be able to be inactive before re-authenticating. Verify user identity in all active sessions if someone performs a password reset. Prompt for authentication or 2nd factor if a user changes core aspects of their profile or when they’re performing a sensitive action. Re-authenticate if the user’s location changes significantly in a short period of time. Consider whether it makes sense to disallow logging in from more than one device or location at a time.

When your service does expire a user session or requires re-authentication, prompt the user in real time or provide a mechanism to preserve any activity they have not saved since they were last authenticated. It’s very frustrating for a user to take a long time to fill out a form, only to  find all their input has been lost and they must log in again.

11. Use 2-Step Verification

Consider the practical impact on a user of having their account stolen when choosing 2-Step Verification (also known as two-factor authentication, MFA, or 2FA) methods. Time-based one-time passwords (TOTP), email verification codes, or “magic links” are consumer-friendly and relatively secure. SMS 2FA auth has been deprecated by NIST due to multiple weaknesses, but it may be the most secure option your users will accept for what they consider a trivial service.

Offer the most secure 2FA auth you reasonably can. Hardware 2FA such as the Titan Security Key are ideal if feasible for your application. Even if a TOTP library is unavailable for your application, email verification or 2FA provided by third-party identity providers is a simple means to boost your security without great expense or effort. Just remember that your user accounts are only as secure as the weakest 2FA or account recovery method.

12. Make user IDs case-insensitive

Your users don’t care and may not even remember the exact case of their username. Usernames should be fully case-insensitive. It’s trivial to store usernames and email addresses in all lowercase and transform any input to lowercase before comparing. Make sure to specify a locale or employ Unicode normalization on any transformations.

Smartphones represent an ever-increasing percentage of user devices. Most of them offer autocorrect and automatic capitalization of plain-text fields. Preventing this behavior at the UI level might not be desirable or completely effective, and your service should be robust enough to handle an email address or username that was unintentionally auto-capitalized.

13. Build a secure auth system

If you’re using a service like Identity Platform, a lot of security concerns are handled for you automatically. However, your service will always need to be engineered properly to prevent abuse. Core considerations include implementing a password reset instead of password retrieval, detailed account activity logging, rate-limiting login attempts to prevent credential stuffing, locking out accounts after too many unsuccessful login attempts, and requiring two-factor authentication for unrecognized devices or accounts that have been idle for extended periods. There are many more aspects to a secure authentication system, so please see the further reading section below for links to more information. 

Further reading

There are a number of excellent resources available to guide you through the process of developing, updating, or migrating your account and authentication management system. I recommend the following as a starting place:

• Our Modern Password Security for System Designers whitepaper (PDF)
• The related Modern password security for users whitepaper (PDF)
• NIST 800-063B covers Authentication and Lifecycle Management 
• OWASP continually updates their Password Storage Cheat Sheet 
• OWASP goes into even more detail with the Authentication Cheat Sheet
• Google Cloud Identity Platform is a multi-protocol customer identity and access management solution, with robust authentication features
• Google’s Firebase Authentication site has a rich library of guides, reference materials and sample code