An app marketplace is an important part of your platform strategy. It helps users discover apps, integrations and extensions which offer new ways to use your product. In addition, it gives developers and partners a way to distribute the apps they build. If you do it right, your app marketplace becomes a competitive advantage. Though there’s great business benefit, your marketplace experience is driven by technology decisions, including how you handle authentication.
It might be tempting to first consider payments. After all, marketplaces and stores would seem to need payments. It’s possible to have a successful app marketplace without running a single transaction. Whether you have authentication—and how you implement it, will impact your marketplace success story.
Authentication determines how deeply you’re able to connect accounts and whether you require separate registration. It also ensures secure access for your users and the developers who are building apps to reach them.
There is a bevy of challenges that come with implementing user authentication. In this post, we’ll be looking at why marketplace authentication is essential, along with the different options available for you when choosing how to authenticate users.
The Importance of Authentication
It’s possible to have a marketplace without authentication. Similar to a marketing website, you can use it to showcase what’s possible on your platform. However, such a site becomes tedious for your team to update (since partners and app developers can’t update content themselves). Plus, it misses out on opportunities to more deeply integrate within the user experience. A robust marketplace will require user accounts, which means you need a plan for authentication.
But before we continue, it’s important to recognize the two distinct roles that need access to your app marketplace:
– Users: those who browse and install apps from the marketplace
– Developers: those who want to add their applications to your marketplace
The first group likely already have accounts for your core product. Many will be customers, with payment details already tied to those accounts. You’ll need to decide whether to use new or existing login credentials and how to handle any marketplace payments. Finally, users will expect any interaction with the marketplace to be connected to their core account. Regardless of how your authentication technology works, they’ll expect it to be seamless.
Developers, on the other hand, may not have existing accounts. Their needs within your marketplace are also very different. A developer wants to submit their app, update its description and understand how it’s performing. If you handle payments, then you’ll also need to consider payouts and what gets displayed within the marketplace admin interface.
Both of these groups need to be authenticated to access your marketplace. The question becomes whether you manually build on to your existing application, create a new authentication system, or attempt to bridge the gap between your marketplace project and core functionality.
Building on to your existing accounts has plenty of issues: tight coupling and roles that might not have meaning elsewhere in your application. Manually implementing new authentication is arduous, too. You would have to create the infrastructure to store and verify credentials on your own, all while ensuring there are no points of weakness in your code. Also, those credentials need to be handled on the server-side. What does that mean? Well, as you create your marketplace, whether in Angular or any other front-end framework, you’ll need to think about what infrastructure to connect to, since client-side authentication is at significant risk for manipulation and should never be trusted.
Luckily, there are protocols and external tools that simplify authentication and ensure data will be protected. When implementing authentication, it’s best not to get creative and instead, trust the experts and standards set.
External Authentication Can Help You
You may have built your own app marketplace or relied on a hosted solution like OpenChannel. In either case, you likely need a way to connect authentication to your primary product. There are existing protocols, like SAML, that are industry standards. You could, of course, implement those protocols on your own. But again, that requires considerable effort, infrastructure and care to get right. For that reason, many turn to using external authentication providers. These are services that handle a lot of the authentication responsibility for you. Through redirects and backend handshakes, a web application uses this external authentication provider to login users and developers.
This process can provide the best marketplace experience, because multiple credentials are not needed. Users can use existing credentials for your marketplace. That’s why these external services are referred to as Single sign-on (SSO) providers; users just need a single set of credentials to sign on.
Two of the most popular providers are now part of the same company:
– Okta: traditionally enterprise-focused
– Auth0: better for startups and simpler use cases
These distinctions are generalizations and authentication can be a complex project, so you’ll want to take a closer look for yourself. However, Auth0 is marketed toward smaller-scale projects, as they even provide an introductory free plan for a limited number of users. Over time, they added features more suited for robust, enterprise-level operations, which is likely why Okta acquired them. Now that they’re a single company, you might expect some of those differences to fade.
You also may find options within your cloud provider:
Regardless of which one you use, you’ll still need to integrate their authentication with your marketplace. All of these providers have authorization code flows that allow you to control access to other applications. The general process looks like this:
- Your application directs to the identity provider’s sign-in page
- User signs in
- The application is given an authorization code
- The application provides this to the identity provider
- The identity provider returns the ID token
- This ID token is then used to access that user’s profile
Of course, this is just one part of building a marketplace. Ideally, the tools you would use to build out other aspects of your marketplace would also work seamlessly with handling user authentication.
Let OpenChannel Streamline Authentication
By now, you’ve probably realized that handling authentication for your marketplace can be overwhelming and complicated. That’s why we’ve addressed the factors that can make it so demanding. The OpenChannel Client API is built for authentication, authorization and data validation. You can use it to handle logged-in users and developers with standard OAuth access tokens. And it works alongside external authentication if you use it.
There are two ways to have OpenChannel’s Client API address authentication. When you have your OpenChannel Client API initially set up, our support team will enable it to have Native or External Authentication.
Native authentication has OpenChannel handle the authentication for you. We get you set up with our OpenID Connect identity provider, which will be used to generate your access tokens. Generating tokens is streamlined with native authentication; simply provide the account credentials in the appropriate call to the API. Native authentication is the default method of authentication for the Client API.
Most developers prefer to use their own preferred SSO identity provider. Users will undoubtedly appreciate being able to login with credentials they already have, as well. For these reasons, we’ve made sure to support seamless integration for external SSO providers. You’ll just need to find how your SSO provider handles authorization with other applications. You can find this information on your specific provider’s documentation.
Whether you’ll want to use native or external authentication, will depend on your situation. It is mainly dependent on if users are already signed up with you. If you already have users make accounts for your own website, then it would make sense to use that same authentication method. When you do so, your users will be able to log in with the same account credentials to access your marketplace.
With all the technical details, it’s easy to forget the end goal: to get users and developers experiencing your app marketplace. Your ability to quickly build and adequately maintain your marketplace will impact the success of your platform strategy. See how top platforms have quickly built a marketplace with OpenChannel. You can get started for free, then integrate the Client API or other aspects of marketplace authentication.