Ask HN: How do you handle user license provisioning for a subscription product?

Have been dabbling the idea of building a product that achieves what you are asking for, but different means to the end that you are seeking.

Happy to talk to you if it piqued your interest.

I have a database table with my customers' subscription and any usage info I need to track. I do have to keep that in sync with their subscription in Stripe. I check that table often to see if a feature is enabled or if a user has remaining resources, so I like having it in a local table (vs querying a service).

Have you looked at https://keygen.sh ?

Maybe I’m wrong, but Keygen seems more focused on licensing the application instance or the device/machine rather than the user.

For us, the application is cross platform. You are granting a user account access to use and be associated with a purchased subscription.

While keygen license keys can be used with user identities, this seems to not be the focus of the product and CIAM integrations are the responsibility of the app developer.

In my scenario, when an organization purchases a subscription with 10 seats, they need to assign which user identities are associated with each available seat.

I think Keygen lacks the ability for the purchasing end-user/customer to manage their own license assignments. It also doesn’t seem to have native integrations with either the identity provider (I.e OAuth support so customer visible keys are unnecessary and the credentialed user account ID effectively serves as the key and prevents key theft) nor does it tie directly to the subscription manager (I.e when a purchase is made the ability to provision which user accounts are associated to subscription is not automatic)

I probably am asking for too much, but this seems like many B2B products do this (Office365, Azure, AWS, Visual studio subscriptions, Adobe creative cloud, Atlassian products etc…). Is there not an out of box product that can do this?

Hey, I'm the founder of Keygen.

I'm sorry that I'm not able to meet your requirements here. Your use-case is one that I'm actually going to be focusing on next year, but one that I don't fully support "out-of-the-box" at the moment. Namely: named user licenses, better subscription support, and a hosted customer-facing portal.

But the good news is that Keygen can currently support this model, just not in the most ideal or straight forward way.

> In my scenario, when an organization purchases a subscription with 10 seats, they need to assign which user identities are associated with each available seat.

Assigning a user maximum isn't currently supported; only a machine maximum. Right now, what my customers with a similar model as yours do, is to use the user's CIAM ID as the machine "fingerprint" and activate them that way -- that way Keygen can validate that user ID X has permission to use license key Y, as well as set limitations on the number of users per-license. (In hindsight, I wish I named the "machine" resource something more generic, because in the real world it's used for a lot more than just machines... maybe for v2. :])

You can hide the license from your customer by storing the license identifiers in your CIAM's user metadata, and then hitting Keygen's API after the user has authenticated and you're able to read those metadata values. E.g. storing the license ID, key and the license's API token is typical.

The license assignment itself would be done after purchase, using e.g. Stripe webhooks to tie a Stripe subscribe event to a Keygen license creation event, assigning any relevant IDs between the 2 services using each resource's metadata. (Or it could be done inline with your purchasing code.)

This could all be done server-side, or mostly client-side, or a mixture.

> I think Keygen lacks the ability for the purchasing end-user/customer to manage their own license assignments.

That is correct, at least from a UI perspective. The API fully supports self-management of a license's resources. But we don't yet offer a customer-facing portal for doing that. A customer-facing license management portal would need to be built out by your team, all backed by Keygen's API.

If you hypothetically did build out the portal, it would need the ability to manage a given license's machine resources, which represent your named users on the license. This can be done using an API token for that license, giving permission for you to manage the license via the API. The token could be stored on the CIAM user so that the end-user never knows about any of the Keygen-related values being used in the background.

Being able to offer a customer-facing portal is one of my priorities in 2022, so I will eventually offer this out-of-the-box.

Thanks for the helpful response.

It sounds like Keygen considers a "subscription" and a "license' to be a 1-to-1 relationship, correct? Most billing/subscription managers I've looked into support the concept of a subscription that supports multiple seats/licenses. To model this in Keygen, the subscription would map to the license and the number of allowed licenses on the subscription would map to the "machines" allowed to use the license, correct? License == Subscription. Machine == Licensed User ID?

While this could work as a quick go-to-market solution I think ideally it would be a many-to-1 relationship between the license (seat) and the subscription. We also want to support the "machine" concept too where we wouldn't want an individual user license to be abused by being concurrently used on multiple devices beyond what an individual user account should be doing (i.e. allow X signed in devices per user).

> You can hide the license from your customer by storing the license identifiers in your CIAM's user metadata, and then hitting Keygen's API after the user has authenticated and you're able to read those metadata values. E.g. storing the license ID, key and the license's API token is typical.

Curious about the distinction between these attributes. Maybe you can educate me: what's the difference between the license ID and license key? And does the API token restrict client access to just that licenses' information? We definitely would be validating licenses from a client/mobile app and not having app level API keys in the mobile client is certainly desirable.

> Being able to offer a customer-facing portal is one of my priorities in 2022, so I will eventually offer this out-of-the-box.

I can see this as being a tall order to get right in the general market sense. Which I'm sure is why few (none?) out-of-box solutions exist. Being able to white label this product will be important. Also supporting the CIAM of your customer so they can be the identity provider/authentication source for their own customers so separate sign in to manage separate accounts/services isn't necessary. Allowing management/license assignment of multiple products with multiple subscriptions etc.. Allowing designation of admin like roles/permissions within the same CIAM directory of your customer securely -- I can see how this can all get hairy real fast. But if you can get it right I can see a market for this.

> It sounds like Keygen considers a "subscription" and a "license' to be a 1-to-1 relationship, correct?

Keygen is actually pretty agnostic when it comes to billing -- if you want to have a one-to-many relationship with a subscription and licenses, you can definitely do that. Keygen doesn’t have a concept of a “subscription”, so third-party records, such as a subscription object in Stripe, can be associated with each other using metadata-based foreign keys for easy lookup on each side.

In the case of multiple licenses -- you can have each license be a “seat” (or named license) and then manage each ones machines separately, like you mentioned, to assert an upper bound on multiple devices per-seat.

> Curious about the distinction between these attributes. Maybe you can educate me: what's the difference between the license ID and license key?

The license ID is a UUID that uniquely identifies it within Keygen’s system. A license key is a value that is more typical of a license, one that can be randomly generated by us upon license creation, or you can also supply a custom value. The license’s key is what most end-users will use, for validations. The ID is used for other requests, such as associating a machine activation to a given license ID.

tldr; different identifiers for different use cases. But in your case, since the end-user wouldn’t be inputting the key themselves, the license’s key is largely irrelevant since you’ll be dealing with the license IDs. (Though the key could be used to assert uniqueness, e.g. setting the key to a named user’s email address hash.)

> And does the API token restrict client access to just that licenses' information? We definitely would be validating licenses from a client/mobile app and not having app level API keys in the mobile client is certainly desirable.

There are different types of API tokens that carry different privileges. But in general, most API requests will require some from of authentication token so that Keygen can assert the token has privileges to perform the request.

This can largely be hidden away, and dynamic per-license, so you shouldn’t need to worry about embedding any tokens into your actual application.

Happy to chat more via email, zeke@ -- HN may not be the best place for long form threads like this. :)

Users get provisioned the first time they click the tile (in Okta). Depending on how it is set up, it will provision basic or licensed accounts when new users click. You can make it so different security groups on AD/Okta get provisioned with different account types.

This seems like it only works if Okta knows how to integrate with your app (How do you create an app Okta knows about that doesn't force customers to use Okta or AD). Also, my understanding is it only works for Okta's paying "Workforce Identity" customers and not app developers using the "Customer Identity" product? Okta creates the provisions to integrate with large market/widely used products (Office 365/Microsoft apps/Atlassian/HR apps-workday etc) but I don't know that they have a way for me as a no-name developer to create the integrations and I don't want to force my customers to also have to be Okta customers. But maybe I'm not understanding?

Look at developer.okta.com/pricing, great free tier. Also you can connect your app via oidc or saml easily. They also include a cloud directory called ud.