Authorize

Asks the CSMS whether an identifier (RFID card, app token) is allowed to start charging.

Version: OCPP 1.6
Direction: Charge Point → CSMS
Feature profile: Core

Authorize also exists in OCPP 2.0.1, with a different payload. See the OCPP 2.0.1 version.

Authorize is how a charge point asks permission before it does anything on behalf of a user. The charger sends the identifier it read — usually an RFID card UID — and the CSMS answers with a status and, optionally, an expiry and a parent token.

A charger with a local authorization cache or list may skip this message entirely when it already holds a valid entry for the token. That is the point of the cache: authorization still works when the backend is unreachable.

Request

Field	Type	Required	Description
`idTag`	IdToken	Required	The identifier presented by the user. Up to 20 characters.

json

[2, "19223201", "Authorize", {
  "idTag": "04A1B2C3D4E580"
}]

Response

Field	Type	Required	Description
`idTagInfo`	IdTagInfo	Required	The authorization decision. See fields below.

json

[3, "19223201", {
  "idTagInfo": {
    "status": "Accepted",
    "expiryDate": "2026-12-31T23:59:59Z",
    "parentIdTag": "FLEET-042"
  }
}]

Values

AuthorizationStatus

Value	Meaning
`Accepted`	The identifier is allowed to charge.
`Blocked`	The identifier is known but has been blocked.
`Expired`	The identifier is known but its validity has passed.
`Invalid`	The identifier is not known to the CSMS.
`ConcurrentTx`	The identifier is already in use in another transaction. Only valid in response to StartTransaction.

Implementation notes

Handle every status, not just Accepted. Firmware that charges on Accepted and ignores the difference between Blocked, Expired and Invalid is the single most common conformance failure we see. All four are normal operating conditions.

ConcurrentTx is only meaningful in a StartTransaction response. Returning it to a bare Authorize is a spec violation, though many chargers tolerate it.