Security introduction

Besides the secured kazi infrastructure, which is explained here, kazi wants to make sure all information about assessments and scores can only be accessed in a secure way. You can only access data via the API and to make sure this API is secure, we choose OAuth2 together with an extra subscription key for authentication to the API.

The reason why we have an extra subscription header, besides the OAuth2 way, is to make sure we can attach different security policies to the requests based on the subscription of the caller. e.g. throttling, limits, high level API restrictions, etc...

You need to be registered and approved by kazi as a legitimate subscriber. In sequence of this registration, the controller (api integrator) will receive a subscription key together with a client id and client secret. Without these keys, it is impossible to access our secured APIs. Follow our getting started page to create a test subscription.

OAuth2

The controller needs to request a secure access token before accessing the API. The application that wants to access the API needs first to be registered at the kazi identity provider. As explained before, the controller will receive a specific client id and client secret for this application and will be granted access to a limited amount of scopes. Based on these scopes in the access token, access is granted or refused for serveral API calls.

At the moment, you can get an access token using two different OAuth grant types:

• Client Credentials grant
• Authorization code grant (preferred)

Kazi subscription header

Together with the access token in the bearer header, you also need to add your subscription key to the Ocp-Apim-Subscription-Key header.

In contrary to the client id and secret, the subscription key is different for each API environment. This means that you need to obtain a different key in test and production