The authorization code flow is very similar to the PKCE one. If you want to read more about it, you can find the information here.

Before starting the flow, generate the STATE. It is a value that can’t be predicted used by the client to maintain state between the request and callback. It should also be used as a CSRF token. Here you can read more information about how to use the STATE.

1. Request authorization code. To do that, you should redirect the user to the /o/authorize page with the following query parameters:

   AUTH_HOSTNAME/o/authorize/?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=REQUESTED_SCOPES&state=STATE
   

   This page asks the user to approve the request from the app to access their account based on the scopes specified in REQUESTED_SCOPES. The user is then redirected back to the specified REDIRECT_URI. The scope parameter is a space-separated list of scopes associated with the user.

   At HealthKey, we currently support two scopes: profile and payment. If you are looking to integrate with us for both authentication and payments, please make sure you include both scopes when making this request.

   The redirect includes the authorization code, as well as the state parameter, if any has been provided:

   https://example.com/oauth/redirect?code=1234567890&state=asdfdfs133

2. With the authorization code returned from the previous request (denoted as RETURNED_CODE in the following example), you can request an access_token, with any HTTP client. Your request should look something like this:

   AUTH_HOSTNAME/o/token/?code=RETURNED_CODE&grant_type=authorization_code&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&redirect_uri=REDIRECT_URI
   

   This type of flow is not recommended for public applications. Even if your application is confidential, we suggest opting for the PKCE flow instead of this one.

   Your response will look something like this:

   {
   "access_token": "de6780bc506a0446309bd9362820ba8aed28aa506c71eedbe1c5c4f9dd350e54",
   "token_type": "bearer",
   "expires_in": 36000,
   "refresh_token": "8257e65c97202ed1726cf9571600918f3bffb2544b26e00a61df9897668c33a1",
   "created_at": 1607635748
   }
   

3. To retrieve a new access_token, use the refresh_token parameter. Refresh tokens may be used even after the access_token itself expires. This request invalidates the existing access_token and refresh_token.

   The redirect_uri must match the redirect_uri used in the original authorization request.

   AUTH_HOSTNAME/o/token/?client_id=CLIENT_ID&refresh_token=REFRESH_TOKEN&grant_type=refresh_token&redirect_uri=REDIRECT_URI&code_verifier=CODE_VERIFIER
   

   An example response will look like this:

   {
   "access_token": "c97d1fe52119f38c7f67f0a14db68d60caa35ddc86fd12401718b649dcfa9c68",
   "token_type": "bearer",
   "expires_in": 36000,
   "refresh_token": "803c1fd487fec35562c205dac93e9d8e08f9d3652a24079d704df3039df1158f",
   "created_at": 1628711391
   }
   

You can now make requests to the API with the access token.