Dailys
Docs

Authorisation (OAuth)

This is a description of the OAuth2 flow from 3rd party web sites. If you have any problems or requests please contact our support team. Dailys uses the OAuth 2 protocol for authorisation.

Using OAuth2 with authorization codes is how most developers are familiar with OAuth2. When using authorisation codes, a client application will redirect a user to dailys where they will either approve or deny the request to issue an access token to the client.

All developers need to register their application before getting started. A registered OAuth application is assigned a unique Client ID and Client Secret. The Client Secret should not be shared. You may create a personal access token for your own use or implement the web flow below to allow other users to authorize your application.

Dailys' OAuth implementation supports the standard authorisation code grant type. Developers should implement the web application flow described below to obtain an authorisation code and then exchange it for a token.

1. Creating OAuth Client

To create a new client application within dailys, you will need to navigate to the developer section of the application.

The client_id and the client_secret should be treated as passwords, and should as such, not be shared. You can generate as many oauth client applications as desired.

2. Requesting Dailys Access

Once a client has been created, developers may use their client ID and secret to request an authorisation code and access token from dailys. First, the consuming application should make a redirect request to /oauth/authorize like so:

URI

GET https://api.dailys.nz/oauth/authorize

Parameters

Parameter Required Type Description
client_id required integer The client ID you received from dailys when you registered.
redirect_uri optional string The URL in your application where users will be sent after authorization. See details below about redirect urls.
scope optional string A space delimited list of scopes. If not provided, scope defaults to an empty list for users that have not authorized any scopes for the application.
response_type optional string The type of response the sender should recieve, by default this is code.

When receiving authorisation requests, dailys will automatically display a dialog to the user allowing them to approve or deny the authorisation request. If they approve the request, they will be redirected back to the redirect_uri that was specified by the consuming application. The redirect_uri must match the redirect URL that was specified when the client was created.

3. Requesting Access Token

If you approve the authorisation request, you will be redirected to your client application. The client should then issue a POST request dailys to request an access token. The request should include the authorisation code that was issued when the user approved the authorisation request.

This /oauth/token route will return a JSON response containing access_token, refresh_token, and expires_in attributes. The expires_in attribute contains the number of seconds until the access token expires.

URI

POST https://api.dailys.nz/oauth/token

Parameters

Parameter Required Type Description
client_id required integer The client ID you received from dailys when you registered.
client_secret required string The client secret you received from dailys when you registered.
code required string The code you received as a response to the authorisation request.
redirect_uri optional string The URL in your application where users will be sent after authorization. See details below about redirect urls.
grant_type optional string The type of oauth grant request being made. Default: code

Response

{
  "token_type": "Bearer",
  "expires_in": 31536000,
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6ImM2ODYxNzA4ZWFlMDM0Y2UxM2ViO...",
  "refresh_token": "WplDqYwDJg4SW9vqih9BxXr/Q2h84++BNiNED6jLLb3cZYNs9wnC2EHpN0hRQRWrcewQbbMa..."
}

When the access_token has been generated for the application you can view the authorised application in the developer section. You can revoke the token using the revoke button and the access_token will no longer be active.

4. Making A Request

Once you have gained your access token, it is your responsibility to keep this token stored securely. You will need to use this token as a HTTP header when making requests to API resource endpoints. You should also ensure that you are using the correct JSON headers when making a request. An example request has been shown below:

URI

GET https://api.dailys.nz/api/v1/user

Headers

Authroization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImp0aSI6ImM2ODYxNzA4ZWFlMDM0Y2UxM2ViO...
Content-Type: application/json
Accept: application/json