0
\$\begingroup\$

So this question is pretty straightforward, but I honestly can't wrap my head around it. How does a client authenticate license from the license provider? For example, when you play a game which hosted on Steam, you will need to login to your account first, then when you run the game, it will check if whether you own the game then it will send you a license.

I understand until this part, but where does the authentication level happen? Is it in the Web API server or is it the local client? If it is on the Web Server, then what did the server send to acknowledge the authenticity and run the game? If it is on the local client, how does the the license pair created (how does the client validator assigned)?

I am thanking in advance for any hint or help.

Edit

To clarify the context of my question, I am building a prototype platform for hosting game(software) and act as a license server. However I am stuck at the authentication method and flow, thus why I use Steam as a reference point based on observation.

I only want to know what is the concept for software licensing especially in client-server relationship.

\$\endgroup\$
2
  • \$\begingroup\$ We probably won't be able to tell you the details of exactly how Steam's solution works. Those may be trade secrets and protected by NDAs, etc. Are you building something similar yourself? If so, try editing your question to describe your context and what you need to accomplish. \$\endgroup\$
    – DMGregory
    Commented Feb 11, 2022 at 12:46
  • \$\begingroup\$ @DMGregory Thanks for the advice, edited for more clarification. \$\endgroup\$
    – Ryugasha I
    Commented Feb 11, 2022 at 13:02

2 Answers 2

1
\$\begingroup\$

First of all, a bullet-proof digital restriction management (DRM) system which reliably stops a user from executing a program which is already on their computer is impossible. You can put barriers in the users path to make it harder for them, but any such barrier can be overcome by a determined user. So forget about creating a solution which is completely impervious to any conceivable attack. All you can do is a solution which is difficult enough to overcome that the average user won't bother.

In the case of Steam, you don't run the game, you ask Steam to run the game. If you look at the properties of any of the shortcuts for Steam games on your desktop, you will notice that they are not actually pointing at the game executable. They are links in the form steam://rungameid/1234567890 . What happens when you double-click on one of these shortcuts (or start the game from the Steam client) is

  1. Steam is launched in the background (if it isn't already running).
  2. Steam asks the user to authenticate with username and password (if they are not already logged in).
  3. Steam contacts the Valve server to confirm that this user has a valid license for this game (some games allow offline play, but they still demand that the last license validation wasn't too long ago).
  4. When the server confirms that the user has a valid license, then and only then does Steam launch the game executable.

Now it would of course still be possible for a technically versed user to locate the game executable in their Steam files and run it directly. In order to prevent this, the game executable might also try to confirm that the user owns the game on Steam on its own. But that's something the game developers would have to implement. For example, by using the Steamworks API in their game (When the user does not own the game on Steam, then even initializing the Steam API will fail). Note that the Steamworks API is not a stand-alone library. It requires a running instance of the Steam client with the user being logged in. Most of the functionality of the library will just contact the Steam client and asks it to fulfill the request. The Steam client might then delegate that request further to the Valve servers.

So the whole Steam DRM scheme hinges on one crucial component: The Steam client. If someone would hack their copy of the Steam client to bypass the license verification, then they could play games they downloaded through Steam and then refunded or copied from another Steam user.

It would also be possible to hack the game executable itself to no longer confirm the license by dummying out any Steamworks API calls. Now it would be possible to create a copy of it and run it without Steam.

\$\endgroup\$
2
  • \$\begingroup\$ I agree, thus why I don't intend to find over complicated DRM method. I also understand about the http requests (which is why I create a web server to host a web api). So to sum up your explanation: 1. Exe check for client is running and logged in, if not run it else don't run. 2. Client call server and do Authentication with the server (the authentication happen in the server and server send yes or no go). 3. Client receive "OK" and run the exe. And to hack it is either from the Client itself or make a dummy api call and reply. If I may, is there any way to "mitigate" dummy api? Thx \$\endgroup\$
    – Ryugasha I
    Commented Feb 12, 2022 at 1:13
  • \$\begingroup\$ @RyugashaI See first paragraph of the answer. \$\endgroup\$
    – Philipp
    Commented Feb 12, 2022 at 9:43
0
\$\begingroup\$

I don't have the answer to how it is implemented by the systems, but I can imagine the mechanism could be based on public and private keys principles. It can be used in two ways; one is to make sure you can trust the sender and the other is to make sure the retriever is the one to be able to decode it.

If a person logs in on the server, the server knows what items that person has purchased. Since a game-PC is registered at the service, a combination of game and PC fingerprints could be used in a licence.

The combination of public and private keys means the server can send a message where the game knows it can only come from the server (because the message can only be decoded with the server's public key) and the game-PC can be identified because the server can decode the message that is encoded with the game-PCs public key. It could be a combination of messages back and forth that complete a validation handshake.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .