API Reference
Log In
API Reference

OAuth

Overview

This guide outlines the steps necessary for integrating the OAuth authentication workflow between an Actor (end user), a Host (client application), and the Quicko.

Workflow Steps

1. Initialisation from Host

  • Actor: The end user who initiates the OAuth flow.
  • Host: The client application requesting access to the Open APIs on behalf of the Actor.
  • OAuth App: The application that manages OAuth authentication.
  • The Host sends an intent along with options (which may include the API key and a redirect URI) to the OAuth App.

2. Actor Consent on OAuth

  • The OAuth App sends an OTP to the Actor to establish their identity.
  • The Actor is presented with a consent screen from the OAuth App to authorise the Host to access Open API.
  • Once consent is given, the OAuth App sends the request token back to the Host.

3. Redirection Back to Host

  • Upon the Actor's consent, the OAuth App issues an HTTP 302 status code, redirecting the Actor to the URI provided by the Host with a Resource Owner's request_token appended as a query parameter.

4. Acquiring Access and Refresh Tokens

  • The Host requests Resource Owner access_token and refresh_token from the OAuth API using the provided request_token.

Understanding Different Tokens

There are various types of tokens that serve different purposes within the OAuth 2.0 framework. This section explains the different tokens involved in the interaction between your app and Quicko. All of the tokens mentioned below belong to the Actor (Resource Owner).

1. Request Token

  • Description: A short-lived token, which the Host must exchange to receive the resource owner's access token.
  • Lifetime: Valid for 10 minutes, to initiate the token exchange.
  • Exchange: Host gets this token after the resource owner (end user) has authenticated and granted consent. It must be exchanged for an access token before it expires.

2. Access Token

  • Description: Used by the Host to access the Quicko's API for that resource owner's data.
  • Validity: Typically expires after 24 hours, requiring a refresh for continued access.
  • Usage: Use in the Authorization header when accessing Open APIs to retrieve resource owner's data.

3. Refresh Token

  • Description: Token for refreshing access, valid for year.
  • Purpose: Used to obtain a new resource owner's access token once the current access token expires.
  • Usage: Securely store the refresh token and use it to request new access tokens without requiring the resource owner to go through the authentication flow again.