You could definitely do that, but it's not an ideal setup because you're locking your user's license and account to a single machine that can and will change. You could offer your users a better user experience (UX) by just letting them create normal email/password accounts, with which their license and machine would be associated with.
You would end up with a few user models (keeping it simple),
class User
has_one :license
has_one :machine, :through => :license
end
class License
belongs_to :user
has_one :machine
end
class Machine
belongs_to :license
has_one :user, :through => :license
end
allowing you to keep track of your users, their licenses and also the machines that they're allowed to use. You could add an attribute to your machine model so that you could store its "fingerprint" e.g. a MAC address may work well here. I've omitted other model attributes (such as a license's "key") for the sake of keeping it simple.
Now whenever your user purchases your product, you can create a new license for their user-account with no machines associated with it. Then when they boot up your product for the first time, you can grab the MAC address of their machine and associate it with the user's license (either in the background or interactively). Bam! Now you can periodically check if the current machine is licensed by sending a basic authenticated request containing the machine's MAC address to your licensing server, responding with the validation result.
Circling back to what I mentioned earlier about providing your users with a superior UX: you now have a way for them to log in using a normal email/password combination (which is what they're used to). From there, you could check their user-account to see if the current machine exists and is licensed. In the end, this is so much better for user on-boarding than requiring them to keep track of and input long cryptic license keys.
(And if you want to get even more user-friendly, you could let them add new machines and purchase additional licenses directly from within your product, because let's face it: they're going to get a new machine eventually and you should make it as easy as possible for them to keep using your product and give you money. Something like a dialog saying, "we noticed you're using a new machine, would you like to purchase a license for this one and/or deactivate an older machine?")
This is obviously starting to get rather complicated though, and we haven't even scratched the surface of things like allowing multiple licenses and machines per-user, floating licenses (one license for many machines—think: a team license), licenses for specific features in the product, or licenses that expire after a certain amount of time (e.g. maybe a limited trial).
Obviously, you don't need to implement all of that and you could keep it as simple as you need it to be. I just wanted to hit on a few issues I've experienced as well as a few thoughts on UX. I've built a few licensing API's and some were of course more complicated than others depending on the product and what type of user-base you're selling to.
Now with all of that said, most of the time developers just want to build their product and not have to worry about also building a licensing system for their product (which can take days or even weeks and in the end just delays your launch, which sucks).
So if you don't want to build your own solution, I built Keygen exactly for this purpose. Keygen is a flexible product licensing JSON API built for developers. Hopefully it provides a way for developers to ship their products sooner and not waste time building licensing servers.
