Resource Owner Password Flow

This flow is available to Clients only — NowInfinity customers accessing their own data. Partners and third-party integrations must use the Authorisation Code Flow.

NowInfinity also recommends the Authorisation Code Flow for Clients. It is more secure, since your integration never handles user passwords, and it gives a clearer audit trail of which user performed which action.

The Resource Owner Password Credentials (ROPC) grant is an OAuth 2.0 flow for trusted clients to obtain an access token by sending a user's username and password directly to the token endpoint.

With this flow you can:

Authenticate a user by sending their credentials to the authorisation server.
Obtain an access token to call the Partner API.
Receive a refresh token, if offline_access is in the granted scope.

There is no browser redirect and no consent screen — which is precisely why it is restricted to integrations accessing their own organisation's data.

Token endpoints

Production: https://auth.nowinfinity.com.au/connect/token
Test: https://auth.nowinfinity-test.com.au/connect/token

Client authentication

The token endpoint accepts client credentials either as form fields in the request body or as an HTTP Basic Authorization header.

To build a Basic header, concatenate the client ID and secret separated by a colon, Base64-encode the result, and prefix it with Basic:

Authorization: Basic {base64(client_id:client_secret)}

The Authorization header is case-sensitive, including the word Basic.

Parameters

Parameter	Required	Value	Description
`grant_type`	Yes	`password`	Must be `password`.
`username`	Yes	String	The username of the resource owner.
`password`	Yes	String	The password of the resource owner.
`scope`	Yes	Space-delimited list	The access being requested. See Authorisation Scopes.

Example request

curl -X POST https://auth.nowinfinity-test.com.au/connect/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password" \
  -d "username={username}" \
  -d "password={password}" \
  -d "scope=api1 read" \
  -d "client_id={your_client_id}" \
  -d "client_secret={your_client_secret}"

Token response

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Property	Description
`access_token`	The JWT used to call the Partner API.
`token_type`	Always `Bearer`.
`expires_in`	Seconds until the access token expires. Read this value rather than assuming a fixed lifetime.
`refresh_token`	Returned only if `offline_access` was in the granted scope.
`scope`	The scope actually granted, which may be narrower than requested.

For unsuccessful requests the response contains an error and an error_description. See Error codes.

Handling credentials

Because this flow requires your integration to handle a user's password directly, a few things matter more than usual:

Never store the password. Use it to obtain a token and discard it.
Request offline_access so you can refresh without re-prompting, rather than holding credentials to re-authenticate later.
Send requests over https only.

Authorisation Code Flow — the recommended alternative.
Managing Access and Refresh Tokens — lifetimes and rotation.
Environments — Test and Production endpoints.