Pulse Introduction

Learn how Pulse is used to secure your Timebase Components.

Pulse is the Timebase Identity Provider (IdP) that enables Collector, Historian, and Explorer security, both user configuration and data management. Pulse provides the following features:

User Management

Users represent the user accounts for people accessing and configuring the Timebase components. At this stage, Pulse provides "built-in" user account management, but will allow for additional Identity Providers, like Active Directory, to be linked to the system in future version.

When creating a new Pulse instance, a default administrative user is created for your convenience: Username Administrator (case-sensitive) and password timebase.

Client Management

Clients represent the applications or components that are registered with Timebase Pulse for authentication and authorization using the OAuth 2.0 Client Credentials flow.

OAuth 2.0 and OpenID Connect (OIDC) are widely used protocols for authentication and authorization. They define different grant types, which determine how access tokens are obtained and used.

When creating a new Pulse instance, default clients are created for securing your Historian:

• Historian client - Client Credentials for securing the Historian API, Code Authorization and Refresh Token to ensure user login for the Historian UI
• Collector client - Client Credentials with "Historian" allowed audience for accessing the Historian API, Code Authorization and Refresh Token to ensure user login for the Collector UI
• Explorer client - Client Credentials for securing the Historian API. Note, Explorer does not currently support user login.

OAuth Basics

Allowed Audiences

OAuth 2.0 provides Allowed Audiences to control clients' access to a resource. This is essential for security to ensure that only specific client services or applications are valid users of these protected resources.

• When an Identity Provider Server issues a token, it includes an aud (audience) claim.
• This claim specifies "who" the token is intended for, such as an API or a service.
• If a service receives a token but isn't listed as an allowed audience, it will be rejected during the token validation process.

Grant Types

OAuth 2.0 provides several Grant Types, each suited for different use cases:

Client Credentials – Used for machine-to-machine authentication, where the client itself is authorized to access resources.

Authorization Code – Used for user account access. The user is granted an authorization code on successful authentication. The client is then authorized to exchange that code for an access token within a limited time window (5 minutes for Pulse).

Refresh Token – Allows clients to periodically obtain a new access token without requiring additional user interaction.

Scopes

OAuth 2.0 and OpenID Connect (OIDC) define Scopes to define what access a client has to a user's information. They control what "actions" are granted when an access token is issued.

Open ID – This is the most fundamental OIDC scope. It ensures that an ID token is returned, confirming the user’s identity.

Profile – Grants access to general user profile information, such as name, picture, and birthdate.

Offline access – This scope allows the client to request a refresh token, enabling it to obtain new access tokens without requiring the user to log in again. This is useful for applications that need prolonged access to a user's data.