oauth2.0: client credentials
All our REST based APIs are secured by the OAuth 2.0 protocol using our Authorization Server. The Authorization Server supports the Client Credentials and Authorization Code Grant flows for
single page application, native device apps and server based applications.
OAuth 2.0 is a fairly simple protocol, and a developer can integrate OAuth 2.0 without too much effort.
On this site you will find documentation on how to use the OAuth 2.0 endpoints provided by the Authorization Server, to obtain access tokens to call a secured API.
1. Create an account and register your organisation
Visit the eWastra Portal and sign in or follow the register link to create a new account.
Make sure that you provide us with all the necessary information to validate,
your application for an account and to validate the organisation you work for.
Please use a correct e-mail address, phone number and VAT Identification number
for your organisation.
Once the administrator rights have been given to your account you can view/edit/create your client credentials.
You can do this on the page https://portal.ewastra.com/Admin , there inside the navigation on the left side you will find a tab Applications.
Once you are on the applications tab you will find a table with the configured client credentials that can be used for this specific organisation.
If there are no client credentials configured for the intended organisation you can configure a new set of credentials following the steps in the following article.
2. Request an access token from the eWastra Authorization Server.
Before your application can access a eWastra API, it must obtain an access token that grants access to that API.
Client Credentials Grant
- Implement this scenario if you need to author (create, issue and manage) consignment notes for your own organization or the organization of a customer.To call the API, you will first need to obtain an access token for the organisation. This can be done using the OAuth 2.0 Client Credentials grant.
Obtain the access token from the token endpoint of our Authorization Server located at https://portal.eWastra.com/oauth2/token
For example, a request for an access token is sent using the client credentials grant type. All necessary parameters are sent form url encoded:
POST portal.eWastra.com/oauth2/token HTTP/1.1
Host: portal.ewastra.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=7979797YIYZYEZ&client_secret=66YD82D2DOZIADDAFDAOD
After successful validation of the client credentials, the server responds with the following response:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"164ajioAEJ6868yUpkk831385",
"token_type":"bearer",
"expires_in":3600
}
When you retrieve an access token, use it in the authorization header to call the API.
For example:
GET /api/v2/transportdocuments/12 HTTP/1.1
Host: portal.ewastra.com
Authorization: Bearer 164ajioAEJ6868yUpkk831385
3. Use the access token to access the eWastra API.
After you have obtained an access token, you can use it an HTTP authorization header. We do not support sending access tokens in the query string, as these query string parameters can be logged in log files that are not completely secure.
The validity of an access token is determined by its lifetime and the scope requested during the token request.
For example:
GET /api/v2/transportdocuments/12 HTTP/1.1
Host: portal.ewastra.com
Authorization: Bearer 164ajioAEJ6868yUpkk831385
4. Refresh the access token, if necessary.
As mentioned in the above steps, access tokens have limited lifetimes. If your application
needs access to an eWastra API beyond the lifetime of an access token,
it can obtain a refresh token. A refresh token allows your application to obtain new access tokens.
Save access and refresh tokens in secure storage and continue to use them as long as they remain valid. Limits apply to the number of refresh tokens that are issued per client-user combination, and per user across all clients, and these limits are different. If your application requests enough refresh tokens to go over one of the limits, older refresh tokens stop working.