API Authentication.
Three types of credentials enable three distinct uses of the API:
Request from 3PLCentral a single-tenant static credential to use the API on behalf of a particular 3PL. You will be given a client id and secret. Do not share this information with unauthorized people, for it can be used to access the 3PL's data.
Use this credential to follow the OAuth2 client_credentials flow, consisting of:
As described in RFC 2617, BASIC authentication requires sending the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials. For OAuth2, the userid and password are the client id and secret.
Assume your client id is fr4zzl3d-g0rp-ni11-b0rk-cr4ck3rj4ck5
and secret is rump3lstiltskin
.
Separate with a colon to form the string fr4zzl3d-g0rp-ni11-b0rk-cr4ck3rj4ck5:rump3lstiltskin
Base64-encode it: ZnI0enpsM2QtZzBycC1uaTExLWIwcmstY3I0Y2szcmo0Y2s1OnJ1bXAzbHN0aWx0c2tpbg==
Use in step 3.
Make a token request as follows:
POST /AuthServer/api/Token HTTP/1.1 Authorization: Basic ZnI0enpsM2QtZzBycC1uaTExLWIwcmstY3I0Y2szcmo0Y2s1OnJ1bXAzbHN0aWx0c2tpbg== Content-Type: application/json; charset=utf-8 Accept: application/json Content-Length: xxx { "grant_type": "client_credentials", "user_login": "guysmiley" }
Note: if using a Single-Tenant dynamic credential, you must also specify a 3PL guid:
"tpl": "[insert the threepl guid here]"
If you encoded a valid client id and secret properly, the response will look like:
HTTP/1.1 200 OK Content-Length: 581 Content-Type: application/json; charset=utf-8 { "access_token":"[access token will be here]", "token_type":"Bearer", "expires_in":3600, // seconds "refresh_token":null, // ignore, this OAuth2 feature not used "scope":null // ignore, this OAuth2 feature not used }
Assume step 3 yielded the token eyJ0eXAiOiJi.eyJleHAiOiIxNDk2MjU0.ASptcg
. In practice, it will be much longer.
Use Bearer authentication in subsequent API requests as follows, making sure to substitute your own token:
GET /customers/17 HTTP/1.1 Authorization: Bearer eyJ0eXAiOiJi.eyJleHAiOiIxNDk2MjU0.ASptcg Accept: application/hal+json
Authentication means who is making the request.
Authorization means to what resources the authenticated requestor is granted access.
The Authorization HTTP header means who, not necessarily what. The process described above is all about who, not what, despite the required use of the HTTP header called Authorization.
A client credential is assigned a set of roles for determining what resources are accessible.
The following HTTP response statuses deal with authentication vs. authorization:
This documentation is subject to change, and is updated often and without warning. The models documented may or may not be available to users now or in the future. Use this documentation at your own risk.
Contact api@3plcentral.com with any questions about this documentation.