OCPP 1.6 has three authorization paths: online (Charge Point sends Authorize to the CSMS and waits for a response), local list (Charge Point checks a CSMS-managed list of pre-approved tokens), and authorization cache (Charge Point reuses the result from a previous online check). All paths return the same idTagInfo structure with a status of Accepted, Blocked, Expired, Invalid, or ConcurrentTx.
Three authorization paths
Online (Authorize)
Charge Point sends the idTag to the CSMS in real time. The CSMS looks up the token in its database and responds with idTagInfo. Requires an active connection.
Local Authorization List
CSMS pushes a token list to the Charge Point using SendLocalList. The Charge Point checks this list first, before going online. Works offline once populated.
Authorization Cache
Charge Point automatically caches idTagInfo from every successful Authorize exchange. On cache hit, it can authorize without contacting the CSMS.
When a token is presented, the Charge Point checks paths in priority order: Local List → Authorization Cache → Online. The CSMS can configure which paths are enabled via configuration keys LocalAuthListEnabled and AuthorizationCacheEnabled.
Authorize message
The Authorize request carries a single field: idTag — a string of up to 20 characters. In RFID deployments this is typically the UID of the NFC/RFID card, hex-encoded. In app-based charging it may be a backend-assigned token string.
idTagInfo response
The CSMS responds with an idTagInfo object. This same structure appears in Authorize responses, StartTransaction responses, and local list entries.
| Field | Required | Description |
|---|---|---|
| status | Yes | Authorization result: Accepted, Blocked, Expired, Invalid, or ConcurrentTx. |
| expiryDate | No | UTC date-time after which this token is no longer valid. If provided, the Charge Point should reject the token after this date even from cache. |
| parentIdTag | No | Group token for fleet/family authorization. If the parent token is Accepted, any child token with this parentIdTag is implicitly authorized. |
| status value | Meaning & Charge Point action |
|---|---|
| Accepted | Token is valid. Allow the session to proceed. |
| Blocked | Token is explicitly blocked. Deny the session and present an error. |
| Expired | Token has passed its expiry date. Deny the session. |
| Invalid | Token is not recognized in the CSMS database. Deny the session. |
| ConcurrentTx | Token already has an active transaction on a different connector. Typically deny — confirm with your CSMS documentation. |
Local Authorization List
The CSMS manages the local list using two messages: SendLocalList (push an update) and GetLocalListVersion (read the current version number). The Charge Point stores up to LocalAuthListMaxLength entries.
Key rules: updateType: "Full" replaces the entire list. updateType: "Differential" merges entries — adding new ones, updating existing ones, and removing entries that have no idTagInfo. The listVersion must be higher than the current version; the Charge Point rejects downgrades.
Authorization Cache
When AuthorizationCacheEnabled is true, the Charge Point automatically stores the idTagInfo from every successful online Authorize response. On subsequent presentations of the same token, the Charge Point can authorize locally using the cached result without sending a new Authorize request.
The cache is not the same as the local list. The CSMS does not manage it directly. Cached entries expire when their expiryDate is reached, or when the CSMS pushes a new version of the token via SendLocalList that overrides the cached result.
Offline authorization
When the Charge Point cannot reach the CSMS, its behavior depends on three configuration keys:
| Configuration key | Effect when offline |
|---|---|
| LocalAuthListEnabled = true | Charge Point uses the local list to authorize tokens. Works fully offline for listed tokens. |
| AuthorizationCacheEnabled = true | Charge Point uses cached Authorize results. Works for tokens seen recently. Non-expired cached entries are accepted. |
| AllowOfflineTxForUnknownId = true | Tokens not in the local list or cache are tentatively accepted and queued for online validation when connectivity resumes. Use with caution in public charging. |
OCPP 2.0.1: IdToken
OCPP 2.0.1 replaces the plain idTag string with an IdToken object. Two fields are required: idToken (the token string) and type (the technology type). The type field enables the CSMS to handle different authentication technologies with different validation rules:
| type value | Technology |
|---|---|
| ISO14443 | Standard NFC/RFID card (Mifare Classic, Desfire) |
| ISO15693 | Long-range RFID |
| MacAddress | Device MAC address (OCPP over Wi-Fi) |
| eMAID | e-Mobility Account Identifier (ISO 15118, Plug & Charge) |
| EVCCID | Electric Vehicle Communication Controller ID (ISO 15118) |
| KeyCode | PIN / numeric code |
| Local | Local account created on the device |
| NoAuthorization | No token — free charging or guest mode |
| Central | Backend-generated session token |
The 2.0.1 response adds new status values: NoCredit, NotAllowedTypeEVSE, NotAtThisLocation, and NotAtThisTime — enabling richer rejection reasons for prepaid accounts and location-restricted tokens.
Common errors
idTag longer than 20 characters
Truncated RFID UIDs are a silent source of authorization failures. Many RFID readers output 28-character UIDs. Truncate to 20 characters consistently and ensure the CSMS database stores the same truncated value.
Local list version not incremented
A SendLocalList with a version number equal to or lower than the current version is rejected by the Charge Point. Always increment the listVersion with every update — even a Differential one.
Not clearing expired cache entries
If AuthorizationCacheEnabled is true and expiryDate is not set, cached entries never expire. Blocked tokens that were previously Accepted may still authorize from cache. Always include an expiryDate when pushing token updates.
Sending Authorize for every transaction when local list is available
Authorize adds round-trip latency to every session start. For frequently-used tokens, use the local list or cache to authorize locally. Reserve the online Authorize for first-seen tokens.
Rodolfo Carrillo
OCPP integration engineer and creator of OCPP Tools. All articles are verified against the official OCA specification and tested using the on-site tools.
Frequently asked questions
What is the difference between the Local Authorization List and the Authorization Cache?
Can a Charge Point start a session without an internet connection?
What is a parentIdTag and when is it used?
What should the Charge Point do if it receives ConcurrentTx from the CSMS?
Is the Authorize message required before every StartTransaction?
What is SendLocalList updateType Differential vs Full?
Sources & further reading
- · Open Charge Alliance. (2015). Open Charge Point Protocol 1.6, Edition 2, §4.1 — Authorize. https://openchargealliance.org/my-oca/ocpp/
- · Open Charge Alliance. (2015). Open Charge Point Protocol 1.6, Edition 2, Appendix 1 — LocalAuthListEnabled, AuthorizationCacheEnabled, AllowOfflineTxForUnknownId. https://openchargealliance.org/my-oca/ocpp/
- · Open Charge Alliance. (2020). Open Charge Point Protocol 2.0.1, §5 — Authorize, IdToken. https://openchargealliance.org/my-oca/ocpp/