Citesphere uses OAuth2 for handling authentication and authorization. You can use any form of OAuth Client to get the token, which needs to be passed to other APIs as a header.

1. Authorizing Application

Prerequisites

You should have created an application in Citesphere. If not, create one!
You should have the following information for the application with you:
- client_id - A unique identifier for your application. This is auto-generated for you during the application creation.
  - Example: OAUTHCLIENT007
- client_secret - An auto-generated secret identifier which will be visible only right after you create the application. If you had lost it, go back and create a new application.
- redirect_url - You should have given a callback URL while creating the application in Citesphere. If you forgot this, you can check it back in Citesphere.

Authorization Flow

From your application, redirect your user to the following URL with specified parameters. Maybe have a button that says which has the hyperlink.

GET /api/v1/oauth/authorize

Query Parameters

Name	Type	Description
`client_id`	`string`	Required. The client ID you received from Citesphere for your App.
`scope`	`string`	Required. A space-delimited list of scopes. Example: `read`
`response_type`	`string`	Required. Tells the authorization server which grant to execute. Example: `code` (In our case)
`state`	`string`	An unguessable random string. It is used to protect against cross-site request forgery attacks. You will need to use the same `state` for the Get Access Token flow if you use the `code` returned by this request as it’s query parameter.

This request will take you to Citesphere, where the user will enter the credentials and or your application.

If the user your application, Citesphere will redirect you back to your application’s redirect_url with the following query parameters.

Name	Type	Description
`code`	`string`	A unique string you should use to get the `access_token` in the next step
`state`	`string`	The same `string` you provided in the previous request.

Example: https://<your_app_redirect_url>?code=xyz123&state=mystate

Note that this step happens in the browser, initiated by your application’s user. That means code and state are visible in the address bar.

Your application should have a controller in the backend to retrieve code and state from <your_app_redirect_url endpoint. That way, you can use code and state to get the access_token from your backend.

2. Get Access Token

This step should NOT be done in the browser. Why? You have to pass your client_secret for getting the access_token.

At any cost, you should NOT expose your client_secret to your user.

`POST /api/v1/oauth/token`

Query Parameters

Name	Type	Description
`client_id`	`string`	Required. The client ID you received from Citesphere for your App.
`client_secret`	`string`	Required. The client secret you received from Citesphere for your App.
`code`	`string`	Required. The code you received as a response in the previous step
`redirect_uri`	`string`	The URL of the application you configured in Citesphere
`state`	`string`	The unguessable random string you provided (and received back) during the previous step.
`grant_type`	`string`	Required. Use `authorization_code` for retrieving an`access_token`. For a list of values, check https://auth0.com/docs/applications/application-grant-types

Response

{
    "access_token": "2c7c0f10-adf5-ed55-a931-caeea29464ee",
    "token_type": "bearer",
    "refresh_token": "0d06219a-1b49-7895-9220-ef3b9810f09d",
    "expires_in": 406,
    "scope": "read"
}

expires_in specifies the number of seconds remaining for the access_token to expire.
You should use the access_token as the Bearer token header for accessing any resource.
- Header Name - Authorization
- Header Value - Bearer 2c7c0f10-adf5-ed55-a931-caeea29464ee
You should use the refresh_token in order to get a new access_token once it is expired

3. Refresh Token

<ToDo>