Authorization Handshake

Let's say we have two services, and The former is a service that makes models printable, the later a service for storing model files. We need to get the two working for our user, Bob, who wants to store the STLs in and send them to

Bob has a model that lives at He wants to provide access to part of his warehouse. First he'll need to create an API key to give to

Content-Type: application/json

    "name"  : "STL Warehouse"

X-Api-Key-Secret: 12345

He then needs to grant the ability for this api-key to access model data

Content-Type: application/json

    "namespace" : "models",
    "actions"   : ["create", "read"],

Now Bob has an API key that he can provide to that has permission to read model data and create new models. He sends the following request to

Content-Type: application/json

    "model"     : "",
    "name"      : "My repair job",
    "callback"  : {
        "method"    : "POST",
        "url"       : "",

This instructs to start a new repair job using the model resource that is found at When the repair job is complete it will send a POST request to with the information about the job that was completed. Both URLs contain the credentials that allow to operate on behalf of Bob.

When makes the request to get the model data it will pass the credentials it was provided as the Authorization header. will then look up the api-key, discover it is a key created by Bob, check that the key has access to read model data, find that it does and then provide the model data to will perform the repair operation on the model and then execute the callback request.

The callback request will look something like this

Authentication: Basic WFlaLVBEUToxMjM0NQ==
Content-Type: application/json

    "name"      : "My repair job",
    "content"   : "",

The name is just a passthrough on the name of the job that the user originally provided. The content is a signed URL that will allow to pull down the contents of the fixed model. This would be similar to how Amazon's S3 service can produce signed URLs with an expiration. The specific security mechanism isn't important, we just need the URL to allow to make a GET request and get the model data. This is necessary because the callback was a POST to the model resource and will create a new model and set the content of that model to the content provided in the URL.

The effectiveness of this scheme relies on several key points:

  • Both services must work over https to protect the API tokens. Any use of http will breach security

  • The services must agree on the signature of the callback requests and match them up in order to create new resources

  • must be able to provide a signed content link

  • The user has to be pretty sophisticated to make this work. But they can make it work

The advantages to this structure include:

  • The user never has to download any large data files. The user is simply orchestrating

  • The system could still work with different authentication mechanisms such as OAuth, the difference would be that there would be more configuration and state

  • Any new service could come along without either service having to know about it and could become part of the ecosystem


Recent Posts

See All

ES6 features to start with

Arrows => Arrows are a shorthand for function. Old way: users.forEach(function(user) { // do something with the user }); New way: users.forEach(user => { // do something with the user }) Impor

Follow us at:

  • LinkedIn
  • Twitter
  • YouTube
  • Facebook

MES for OEMs

MES for Service Bureaus

Extension Modules


Company Overview




Machine Integrations

Software Integrations

Contact Us

Philadelphia, PA, USA

Member of

Privacy Policy

Terms of Use