Authentication vs. Authorization in Platform Connections

Hello again. In the previous lesson, you read a JSON telemetry message and separated what its fields reported from what still needed verification. Earlier, you also distinguished a platform identity from the roles and permissions assigned to it. Those ideas meet when a device, gateway, or person connects to a building platform: how does the platform know who is connecting, and how does it decide what that connection may do?

This lesson focuses on those two questions. By the end, you should be able to distinguish an authentication failure from an authorization failure in a platform connection, without assuming that a successful sign-in grants access to everything. Allow about 35–40 minutes, including the short video and readings.

Two questions behind a connection

The first question is “Who or what are you?” Authentication verifies a claimed identity. A person might supply a password and a second factor; a software component or device might present another form of credential. The second question is “May you perform this action on this resource?” Authorization determines whether the identified person or component has the required access.

Okta’s illustration puts the distinction side by side. The login screen represents identity verification; the permissions screen represents a separate decision about access.

Watch how Authorization vs Authentication – Whats the Difference?, from Roberts Dev Talk, uses a workplace badge to explain why a valid identity does not open every door. Then follow its translation of that idea to an application.

The badge analogy has a useful limit: a platform need not store every permission on a token or badge. It may also check current roles or policies elsewhere. The essential distinction is the decision, not where the permission information is stored.

Microsoft Learn’s Identity and Access Management (IAM): Core Concepts and Benefits states the distinction for people, software components, and hardware devices. Read the definitions and the first part of its comparison; you can leave the protocol details for another time.

It is tempting to collapse the two questions into “Can it connect?” Resist that shortcut. An identity can be genuine yet lack a particular permission. Conversely, assigning a permission to an account does not make a request from someone who cannot prove control of that account trustworthy.

Follow a telemetry upload

Consider an illustrative connection: an edge gateway at North Tower sends AHU telemetry to a cloud platform. The names and access rules below are examples for reasoning, not a statement of Building X’s connection requirements.

Suppose the gateway uses a software identity named north-tower-gateway. A request attempts to upload the JSON payload you saw in the previous lesson. Three separate matters must be established:

1. Can the request reach the service? DNS, routing, and firewall rules affect whether network communication is possible. They do not establish the caller’s identity or permissions.
2. Can the gateway prove its identity? The service verifies an accepted credential or other proof associated with north-tower-gateway. That is authentication.
3. Is that identity permitted to upload this data here? The platform evaluates the requested action and resource against its access rules. That is authorization.

The third question needs more precision than “the gateway has access.” Access to what, to do what, and within which scope? In this example, permission to submit telemetry for North Tower would not imply permission to change user roles, read another customer’s data, or upload to another tenant. A tenant is the platform boundary discussed earlier; an identity and its role or permissions must be considered within the applicable boundary.

A role can make permissions easier to manage: rather than configuring each allowable action separately for every gateway, a platform may assign a suitable role to the identity. But role assignment belongs to authorization. It does not replace the gateway’s need to authenticate. Nor does a field such as "equipmentId": "AHU-01" inside the uploaded JSON authenticate the sender: that field is content supplied by the sender, not independent proof of who sent it.

For an API-based version of this connection, Microsoft Learn’s API Authentication and Authorization – Azure shows one common pattern involving an access token. It is an example of a possible design, not a universal requirement for building platforms.

In that example, the caller obtains a time-limited access token and presents it to the API. The receiving service validates the token and decides whether the request meets its access rules. Authentication and authorization are distinct even when an application makes them feel like one uninterrupted connection. Other systems may use different credentials and enforcement arrangements, so consult the product’s current documentation before specifying how a real integration works.

Tell a failed identity check from a denied permission

Imagine three results for the North Tower gateway:

The last row matters: an accepted request is not proof that its telemetry is correct. Authentication concerns the sender’s identity; authorization concerns permitted access. Data quality is another question.

When investigating a real failure, describe the evidence before naming the cause. An error response, log entry, or product message may distinguish an unrecognized credential from a recognized identity lacking permission. Many HTTP APIs use 401 for a request that has not met authentication requirements and 403 for a request that is not permitted, but implementations vary; check the service’s own documentation and logs. A timeout or inability to reach an endpoint is different again: the request may never have arrived for either access check.

The practical troubleshooting question is therefore not merely “Does the account work?” It is: Which identity made which request, for which action and resource, under which tenant or scope—and at what stage was it rejected? That phrasing gives colleagues something specific to verify while avoiding an unnecessary grant of broader access.

Key takeaways

Authentication verifies the claimed identity; authorization decides whether that identity may perform a particular action on a particular resource. People, devices, and software components can all be subject to both checks. A valid credential does not confer universal access, and an identity or equipment ID written inside a JSON payload is not proof of who sent it.

For a platform connection, keep network reachability, identity verification, permission checks, and telemetry quality separate. Next lesson, you will examine how TLS certificates help protect building data in transit—a related security concern, but not a substitute for deciding what an authenticated connection is allowed to do.