Skip to main content
Get Token permission allows you to create access tokens on behalf of the authorizing user. This can be used to create plugins or to achieve user login authentication (for licensing). It gives you access to a range of methods: AuthorizeApp (in some cases, token is needed), GetChallenge and GetToken methods.

​
General

The idea behind the way your application can receive a token from an SKM user contains three parties:
  • Vendor - the vendor who develops the application.
  • App - the instance of your application that attempts to retrieve the token.
  • User - the person who will authorize the app to create a token on their behalf.
All of the parties above have different responsibilities.

​
Vendor

The vendor should create a token with GetToken permission (aka parent token). This is used to authorize the app to create authorization requests on their behalf. Apart from this, the vendor has the ability to customize the properties of the generated tokens (aka child tokens). For example, the key lock parameter can be used to set an upper bound for how long the new token will be valid. Although it’s better to set it to a longer date (say 30 to 60 days), there may be cases when you want to have a shorter time span. From the perspective of the vendor, there are no major security concerns. The user, on the other hand, would benefit from having a shorter time span, since they can control who can access their keys (and other data). You should always, despite the scope of the token, treat the new access token as a password and store it in a secure location. The user has entrusted you to do so.

​
App

The app is responsible to create an authorization request (that the user has to accept) and later solve a challenge provided by SKM to get a new token. The app will never see the actual user name and password if configured properly, and the only thing it knows is the new access token authorized by the user. In this way, the user can always remove the access token, which would require a new authorization request. The should generate a new RSA 2048 key pair for each authorization request (it could be done fewer times, but then it’s important to keep the keys in a safe place). Only the public key should be sent to SKM; the private key will be used to solve the challenge.

​
User

The user is the one who lets the app to access the license keys (just an example) without exposing the credentials to the vendor nor the app. The app will only posses an access token that belongs to the user and the user can always block the access if desired.

​
Plug-ins

If your app requires access to certain methods that belong to the user, you can ask the user to authorize this as described above.

​
User Login Auth

User login authentication mechanism is very similar to the plug-in example. The only difference is that we also keep track of machine codes. When you initiate an authorization request, you will specifically ask the user to authorize their device. This helps you to keep track of how many devices they are running on and you can always specify the limit by editing their customer profile. Note, in contrast to the general case, user login auth requires you to have an active association between the customer (in the control panel) and an existing customer in SKM. Another unique feature of user login auth is that you can control some methods as a vendor. For example, GetLicenseKeys method will look at the parent token’s feature lock to determine how much information should be shown for each license key. To obtain this value, please use the following tool. You can also use product lock in the same way you would normally use it.