Authentication and authorization
Hackolade Studio is a client-only application. Whether it runs as a desktop application or in a browser tab from https://studio.hackolade.com, no Hackolade server is used.
Data models are JSON files stored in your own Git repositories, and Studio reads and writes them directly, whether you useGitHub, GitLab, Bitbucket, or Azure DevOps. Hackolade maintains no user directory and holds no customer data, so the application has no account for anyone to log in to.
Hackolade Studio delegates authentication and authorization to the storage layer, i.e. your Git repository provider which handles, using the identities, roles, and review policies of your organization. As a result, the sign-in prompt appears the first time Studio accesses a repository, not when the application opens.
The narrative for this sequence diagram can be found below.
1. No login prompt when you launch Studio
When the user opens the desktop application or navigates to https://studio.hackolade.com, the workspace opens up directly and Studio requests no credentials. The user can start modeling right away, with no network authentication.
2. First access to a repository: authentication
The first time the user opens a data model from a repository (File > Open From), or saves a data model to a repository (File > Save To), or follows a shared model link, Studio prompts for a one-time connection setup. The requested information includes the provider, its host name for self-hosted instances, and the sign-in method. Depending on the provider and how it is hosted, Studio connects through OAuth or a personal access token.
With OAuth, Studio redirects the user to the provider's own sign-in page. If the provider is federated with a corporate identity provider such as Microsoft Entra ID, then the user signs in through that single sign-on, subject to the organization's MFA and conditional access policies. The user then consents to a limited set of scopes, and the provider issues an access token to Studio. Studio never receives the user's password.
On GitHub cloud, Studio in the browser signs in through a GitHub App named Authorization for Hackolade Studio. An organization administrator installs the app and limits it to selected repositories, so users only reach repositories that are both within the app's scope and within their own permissions. Connections to self-hosted GitHub Enterprise Server use personal access tokens, as OAuth is not provided.
With a personal access token, the user generates the token in the provider's web interface, limited to the scopes Studio requires, and with an expiration date, then pastes it into the Studio connection dialog. An administrator or the user can revoke the token from the provider at any time.
In both cases, Studio calls the provider's API with the token, and the provider returns the user's identity and the repositories available to that user. Users who work in a locally cloned repository with the desktop application authenticate through their Git client instead, typically the Git Credential Manager with browser sign-in, or SSH keys. Studio does not store those Git credentials. They are stored in the Git client's credential store.
The process is documented, for each provider, in these pages.
3. Open a model: read permission
When the user picks a repository, branch, and folder, then opens a data model, Studio requests the JSON files from the provider with the user's token. The provider checks the user's role on that repository before returning anything.
With read access, the provider returns the files and the data model opens in Studio. Without read access, the request fails with an access-denied error. Repositories outside the user's permissions do not appear in the repository list in the first place.
4. Save a model: write permission and branch rules
To save a data model, Studio sends the commit to the target branch, and the provider checks both the user's write access to the repository and the rules configured on that branch. When the user has write access and no rule blocks direct pushes, the provider records the commit under the authenticated user's identity.
When a repository administrator has protected the branch, for example by requiring pull requests, the provider rejects a direct push. From Studio, the user then pushes the changes to a new branch and submits them for review as a pull request that targets the protected branch. Reviewers and maintainers can examine the proposed changes in Studio's graphical compare view, and the provider enforces the repository's policy, such as required reviewers or a minimum number of approvals, before it allows the merge.
Because every request goes to the provider with the user's own token, the provider applies the same access rules to data models as to any other content in those repositories. When an administrator removes a user's access to a repository or revokes the token, the provider denies that user's next request, and there is no separate Hackolade user list to keep in sync. The provider's commit history, pull request records, and audit logs show who changed each model and who approved the change.