Table of Contents

Authorization & Identity

Authorization in OCPP happens at two distinct points, and it helps to keep them separate:

  1. User authentication — confirming that the identifier a driver presents (an RFID card, NFC tag, or app token) is valid. The charger sends an Authorize request and the CSMS responds.
  2. Transaction authorization — the identifier that authenticated the user is carried into the transaction when charging starts, and the CSMS confirms (or rejects) the transaction in its response to the transaction start message.

A user can be authenticated but still not permitted to start a given transaction; in that case authentication succeeds and the transaction is subsequently rejected. Transaction handling is described in Transactions; this page covers identification and the Authorize flow.

Identity

In most cases charging is authorized by first identifying the driver. Identification is usually done by the charger reading a physical RFID card or NFC tag that the user presents. After a valid card or tag is presented, the charger asks the CSMS to authorize the identifier, and the CSMS responds indicating whether the identifier is valid.

When a facility is managed by Enua, users can register RFID cards or NFC tags themselves in the Enua app, available on the Apple App Store or the Google Play Store. They can also authorize directly from the app without scanning a physical card. If the facility is managed by another operator, registration goes through that operator.

Note

Authentication is only required when the facility is not configured for free charging. See Custom Extensions → Free Charging.

The Authorize flow

When a user presents an RFID/NFC token, the charger sends an Authorize request to the CSMS.

sequenceDiagram
    actor User
    participant CS as Enua Charging Station
    participant CSMS as Your CSMS
    User->>CS: Present RFID / NFC token
    CS->>CSMS: Authorize {idToken}
    CSMS-->>CS: AuthorizeResponse {status}
    alt status = Accepted
        CS->>CS: Ready to start a transaction with this idToken
    else not Accepted
        CS->>User: Reject (no charging)
    end

Authorize request

[
    2,
    "36cf73c6-a2d3-4909-b298-8d323e350f0b",
    "Authorize",
    {
        "idToken": {
            "idToken": "<RFID/NFC token>",
            "type": "ISO14443"
        }
    }
]

Authorize response

The CSMS responds indicating whether the identifier is authorized.

[
    3,
    "36cf73c6-a2d3-4909-b298-8d323e350f0b",
    {
        "idTokenInfo": {
            "status": "<AuthorizationStatusEnumType>",
            "cacheExpiryDateTime": "<dateTime>"
        }
    }
]

AuthorizationStatusEnumType

Value Description
Accepted Identifier is allowed to charge.
Blocked Identifier has been blocked. Not allowed to charge.
ConcurrentTx Identifier is already involved in another transaction and multiple transactions are not allowed. (Only relevant to the response of a TransactionEvent with eventType = Started.)
Expired Identifier has expired. Not allowed to charge.
Invalid Identifier is invalid. Not allowed to charge.
NoCredit Identifier is valid, but the driver doesn't have enough credit to charge.
NotAllowedTypeEVSE Identifier is valid, but not allowed to charge at this type of EVSE.
NotAtThisLocation Identifier is valid, but not allowed to charge at this location.
NotAtThisTime Identifier is valid, but not allowed to charge at this location at this time.
Unknown Identifier is unknown. Not allowed to charge.

Remote and automatic authorization

Besides presenting a token, a session can be authorized in two other ways:

  • Remote start — the CSMS supplies the identifier and starts the transaction itself. See Remote Control.
  • AutoCharge — the charger derives an identifier from the vehicle automatically, without a card or app. See Custom Extensions → AutoCharge.

Offline behavior

An Enua charger can authorize a presented identifier while offline using two OCPP mechanisms:

  • Authorization Cache — a rolling cache of identifiers the CSMS has recently accepted. Entries are cached for as long as the AuthorizeResponse specifies. When the cache is full, the oldest entry is replaced.
  • Local Authorization List — a list of identifiers the CSMS explicitly manages on the charger via SendLocalList.

When both are present, the Local Authorization List takes priority over the Authorization Cache for the same identifier. The charger resolves an identifier in this order:

  1. Local Authorization List
  2. Authorization Cache
  3. Authorize request to the CSMS (when online)

Enable these features with the following configuration:

Set AuthCacheCtrlr.AuthCacheEnabled to true to enable the Authorization Cache. See Supported Configuration Keys.