1.2 Authentication

The DHIS2 Web API supports two protocols for authentication, Basic Authentication and OAuth 2. You can verify and get information about the currently authenticated user by making a GET request to the following URL:


And more information about authorities (and if a user have a certain authority) by using the endpoints:


1.2.1 Basic Authentication

The DHIS2 Web API supports Basic authentication . Basic authentication is a technique for clients to send login credentials over HTTP to a web server. Technically speaking, the username is appended with a colon and the password, Base64-encoded, prefixed Basic and supplied as the value of the Authorization HTTP header. More formally that is Authorization: Basic base64encode(username:password) Most network-aware development frameworks provides support for authentication using Basic, such as Apache HttpClient, Spring RestTemplate and C# WebClient. An important note is that this authentication scheme provides no security since the username and password is sent in plain text and can be easily decoded. Using it is recommended only if the server is using SSL/TLS (HTTPS) to encrypt communication between itself and the client. Consider it a hard requirement to provide secure interactions with the Web API.

1.2.2 OAuth2

DHIS2 supports the OAuth2 authentication protocol. OAuth2 is an open standard for authorization which it allows third-party clients to connect on behalf of a DHIS2 user and get a reusable bearer token for subsequent requests to the Web API. DHIS 2 does not support fine-grained OAuth2 roles but rather provides applications access based on user roles of the DHIS2 user.

Each client for which you want to allow OAuth 2 authentication must be registered in DHIS2. To add a new OAuth2 client go to Apps > Settings > OAuth2 Clients , click add new and enter the desired client name and the grant types. Adding a client using the Web API

An OAuth2 client can be added through the Web API. As an example we can send a payload like this:

   "name" : "OAuth2 Demo Client",
   "cid" : "demo",
   "secret" : "1e6db50c-0fee-11e5-98d0-3c15c2c6caf6",
   "grantTypes" : [
   "redirectUris" : [

curl -X POST -H "Content-Type: application/json" -d @client.json
  -u admin:district $SERVER/api/oAuth2Clients

We will use this client as the basis for our next grant type examples. Grant type password

The simplest of all grant types is the password grant type. This grant type is similar to basic authentication in the sense that it requires the client to collect the users username and password. As an example we can use our demo server:


curl -X POST -H "Accept: application/json" -u demo:$SECRET $SERVER/uaa/oauth/token
-d grant_type=password -d username=admin -d password=district

This will give you a response similar to this:

   "expires_in" : 43175,
   "scope" : "ALL",
   "access_token" : "07fc551c-806c-41a4-9a8c-10658bd15435",
   "refresh_token" : "a4e4de45-4743-481d-9345-2cfe34732fcc",
   "token_type" : "bearer"

For now, we will concentrate on the access_token , which is what we will use as our authentication (bearer) token. As an example we will get all data elements using our token:

curl -H "Authorization: Bearer 07fc551c-806c-41a4-9a8c-10658bd15435" $SERVER/api/26/dataElements.json Grant type refresh_token

In general the access tokens have limited validity. You can have a look at the expires_in property of the response in the previous example to understand when a token expires. To get a fresh access_token you can make another round trip to the server and use refresh_token which allows you to get an updated token without needing to ask for the user credentials one more time.


curl -X POST -H "Accept: application/json" -u demo:$SECRET $SERVER/uaa/oauth/token
-d grant_type=refresh_token -d refresh_token=$REFRESH_TOKEN

The response will be exactly the same as when you get an token to start with. Grant type authorization_code

Authorized code grant type is the recommended approach if you don’t want to store the user credentials externally. It allows DHIS2 to collect the username/password directly from the user instead of the client collecting them and then authenticating on behalf of the user. Please be aware that this approach uses the redirect_uris part of the client payload.

Step 1: Using a browser visit this URL (if you have more than one redirect URIs, you might want to add &redirect_uri=http://www.example.org) :



Step 2: After the user have successfully logged in and accepted your client access, it will redirect back to your redirect uri like this:


Step 3: This step is similar to what we did in the password grant type, using the given code, we will now ask for a access token:


curl -X POST -u demo:$SECRET -H "Accept: application/json" $SERVER/uaa/oauth/token
  -d grant_type=authorization_code -d code=XYZ