The Class API uses OAuth 2.0 and OpenID Connect to enable a single sign-on experience for Partner applications.
1. Request authorisation. Request authorisation from Class. The end user authenticates, including MFA, and Class returns an authorisation code.
2. Exchange the code. Exchange the authorisation code for an access token and, if requested, an ID token.
3. Verify. Verify the claims in the ID token, then use the access token to retrieve claims from the UserInfo endpoint or to call the resource APIs.
This is the Authorisation Code Flow with openid included in the requested scope.
The user grants permission for the Partner application to access a resource — an SMSF fund's details, for example — on their behalf. The Partner application receives an access token, which it uses to call the resource APIs.
OAuth 2.0 handles authorisation: what your application is allowed to do.
OpenID Connect extends OAuth 2.0 to handle authentication: who the user is. It is what makes SSO between OAuth-enabled applications possible.
OIDC adds a JSON Web Token (JWT) called an ID token. Where OAuth 2.0 leaves the meaning of scopes up to the implementer, OIDC standardises a set focused on identity.
Include openid in your requested scope to receive an ID token. That also unlocks further claims — email, address, phone_number, class_profile and others — which must be requested alongside openid. See UserInfo Endpoint for the full set of available claims.
Class ID tokens are JSON Web Tokens signed using public key cryptography. They are returned only when the authorisation scope includes openid, and are valid for 20 minutes.
An ID token has three parts: a header, a payload and a signature. The header and signature verify the token's authenticity; the payload carries the information about the user.
Always validate ID tokens. Applications that use ID tokens for authorisation are granting access on the strength of them. Use an established token validation library rather than parsing tokens yourself — libraries are available for most languages and frameworks.
{
"typ": "JWT",
"alg": "RS256",
"kid": "1C438CF0-6183-4E36-A8A8-D9565D716379"
}{
"sub": "2e0742e2-ae4f-4ded-a478-fc5b2bb63b3e",
"email": "firstname.lastname@email.com",
"urn:Class:specialroles": "",
"iat": "1724814986",
"at_hash": "QUo7KqrK2Bme0ANgyVi_Hw",
"iss": "https://app.class.com.au/",
"aud": "d6044958-95a0-4695-8b73-4011e4b4d541",
"exp": 1724816186,
"nbf": 1724814986
}| Claim | Description |
|---|---|
sub | Uniquely identifies the user. |
kid | The thumbprint of the public key used to validate the token's signature. |
iat | When authentication for the token occurred, as a Unix timestamp. |
iss | The issuer that constructed and returned the token. In production this is https://app.class.com.au/; in PIE, https://app.class-pie.com.au/. Validate against the environment you are configured for. |
aud | The intended recipient — your application's OAuth client ID. Reject the token if this does not match your client ID. |
exp | The expiry time, after which the token must not be accepted. A resource may reject a token before this time, for example if re-authentication is required or a revocation has been detected. |
nbf | The time before which the token must not be accepted. |
- Authorisation Code Flow — the flow SSO is built on.
- UserInfo Endpoint — retrieving further claims.
- Authorisation Scopes — which scopes unlock which claims.
- Environments — issuer values per environment.