In this article, we will go through what Class uses for authentication and Authorization.
- We Use OAuth 2.0 framework with Bearer tokens to manage authorization when accessing the API.
- Implements the OpenID Connect identity layer for authentication and obtaining user information.
- Clients that have multiple businesses within Class, one client credential will be issued but to pull the API's you will be required to get individual access tokens for each separate business. Please example model below.
Before accessing the API, you will need a set of client credentials, issued by Class.
For instructions on how to register your integration and obtain these credentials, refer to the Steps to use Class API page.
We support a number of common OAuth authorization flows depending on the nature of your client application.
In this article, we provide you with an overview of the basic steps required to access the Class API
- Obtain OAuth 2.0 credentials
These credentials are obtained from Class, as described on the Steps to use Class API page.
- Obtain an Access Token
- Access API using the Access Token
When making requests to the Class API, the access token must be sent in the HTTP authorisation header. The header must be in the Bearer token format.
The authorization header is case-sensitive, including the word
Authorization: Bearer Orh1Vz8T...
- Refresh the Access Token using the Refresh Token
For security reasons, access tokens have a limited lifespan. When the access token expires, a new access token and refresh token can be obtained using the refresh token in step 2.
Refresh tokens are not available for all authorization flows, refer to the page for the specific flow your integration uses for instructions on how to obtain and use refresh tokens for that flow.
Authorization Code Flow
Suitable for web server applications. The source code of the application won't be shown to the public, the client application will not see the users credentials. The client is issued an authorization code and access token.
Resource Owner Password Flow
Suitable for use by private clients. used with trusted Applications, such as those owned by the service itself (Class users accessing their own data via the API). The client credential can be seen so if you trust the server you can use this flow. The client is issued an access token only.
Client applications should anticipate and handle the case that an OAuth 2.0 token may no longer be valid. Tokens may become invalid for a number of reasons:
- The user who authorised the token has explicitly revoked access
- Time-based expiry, depending on the type of grant/token
Grant/token typeValid for
Authorization code 5 minutes Access token 15 minutes Refresh token 30 days
For more detailed instructions specific to your use case, refer to the following pages: