Authentication & Access Control
D.Hub provides a multi-layered security system for user authentication and resource access control. It supports various authentication methods including local authentication, OIDC SSO, and service tokens, and implements fine-grained per-resource permission management through Relationship-Based Access Control (ReBAC).
Authentication Methods Overview
D.Hub provides three authentication methods. You can choose the appropriate method based on your environment and use case.
| Auth Method | Use Case | Token Type |
|---|---|---|
| Local Auth | Direct login with username/password | JWT (Access + Refresh) |
| OIDC SSO | Single sign-on via external IdP | JWT (Access + Refresh) |
| Service Token | Automation scripts, CI/CD pipelines, etc. | Long-lived token |
Local Authentication
Local authentication is a login method using a username and password directly registered in D.Hub.
Authentication Flow
- The user enters their username and password on the login screen
- The server verifies the password against the Argon2 hash
- Upon successful authentication, a JWT Access Token and Refresh Token are issued
- The client includes the Access Token in all subsequent API requests
JWT Token Structure
| Token | Purpose | Validity |
|---|---|---|
| Access Token | Bearer token used for API request authentication | Short-lived (default 30 minutes) |
| Refresh Token | Used to obtain a new token when the Access Token expires | Long-lived (default 7 days) |
When the Access Token expires, the client automatically obtains a new Access Token using the Refresh Token. If the Refresh Token has also expired, the user must log in again.
OIDC SSO
Through OIDC (OpenID Connect) SSO, users can log in to D.Hub with accounts managed by an external IdP. Users can access directly with their existing organizational account without needing to create a separate D.Hub account.
Supported IdPs
| IdP | Protocol | Notes |
|---|---|---|
| Keycloak | OIDC / OAuth 2.0 | Self-hosted IdP |
| Azure AD | OIDC / OAuth 2.0 | Microsoft cloud IdP |
| Zitadel | OIDC / OAuth 2.0 | Cloud-native IdP |
SSO Authentication Flow
Users who log in via SSO for the first time are automatically registered in D.Hub, and admins can then assign roles on the User Management screen.
Service Tokens
Service tokens are authentication credentials used by applications or automation scripts (not humans) to call the D.Hub API. They are issued by an admin and used as Bearer tokens just like regular JWTs.
Service Token Characteristics
- Long-lived: Unlike regular Access Tokens, no expiration period is set
- Role-based: A specific role (
adminoruser) is assigned to the token - Audit trail: API calls made through the token are logged along with the issuer information
Since service tokens do not expire, they are suitable for use in automation scripts, CI/CD pipelines, and external system integrations. However, be careful about leakage and store them securely in environment variables or a secret manager.
Usage Example
curl -H "Authorization: Bearer <SERVICE_TOKEN>" \
https://dhub.example.com/api/v1/datasets
Authentication Flow Summary
Access Control (ReBAC)
D.Hub uses Relationship-Based Access Control (ReBAC). Unlike traditional Role-Based Access Control (RBAC), permissions are determined based on the relationship between users and resources.
Core Concepts
| Concept | Description |
|---|---|
| Resource (Object) | An item within D.Hub that is the target of access (Collection, Knowledge, etc.) |
| Relation | The role between a user/group and a resource (owner, editor, viewer) |
| User | The access subject (individual user or group) |
Permissions by Role
| Role | View | Edit | Delete | Manage Permissions |
|---|---|---|---|---|
| viewer | ✅ | |||
| editor | ✅ | ✅ | ||
| owner | ✅ | ✅ | ✅ | ✅ |
Roles work hierarchically. owner includes all permissions of editor, and editor includes all permissions of viewer.
Configuring Access Permissions
You can grant access permissions to users or groups from the resource's settings screen:
- Navigate to the Settings tab of the resource (Collection, Knowledge, etc.)
- Click the Add Permission button in the Access Control section
- Select the target (individual user or group) and assign a role
- Click the Save button to apply immediately
Group-Based Access Control
Granting access permissions to groups instead of individual users allows for efficient management. When a group's membership changes, all resource access permissions granted through that group are automatically reflected.
Group "data-team" → Collection "sales-data" (editor)
├── alice (group member) → can edit sales-data
├── bob (group member) → can edit sales-data
└── carol (group member) → can edit sales-data
For details on group creation and member management, see the Group Management document.
The user who creates a resource is automatically assigned the owner role. The owner can add or remove permissions for other users or groups.
Next Steps
| Document | Description |
|---|---|
| User Management | View users, create users, OIDC sync |
| Group Management | Group creation, member management, OIDC sync |
| API Reference - Auth | Authentication API detailed specification |