Security and Permissions

This page covers what the app accesses, how credentials are stored and protected, and how to revoke access fully.

GitLab scopes and what they allow

Information about GitLab scopes and what they allow.

The app requests two GitLab OAuth scopes. Both are required.


Scope	What it allows
`api`	Read and write access to the GitLab API — needed to create and update work items
`read_api`	Read-only access to the GitLab API — needed for listing projects, work items, labels, milestones, and members

These scopes are set in the self-managed OAuth application registration.

Credential storage

Information on how and where credentials are stored in the app.

All credentials: OAuth access tokens, OAuth refresh tokens, Personal Access Tokens, and self-managed OAuth application secrets, are encrypted at rest.

Encryption: AES-256 via AWS Key Management Service (KMS). Credentials are encrypted at the application layer before being written to the database. No plaintext credentials are persisted at any layer.
KMS key rotation: Enabled. The app uses a customer-managed KMS key with automatic rotation.
Decryption on demand: Credentials are decrypted at request time, per request, and only for the operation in progress. Decrypted values are held in ephemeral Lambda memory and are not cached between requests.

The GitLab for Miro app does not store Miro board content beyond the identifiers needed for two-way sync: Miro card IDs and their mapping to GitLab work item IDs.

Per-user vs team-level credential models

Details about how different credentials are stored by the app.

The app supports two authentication models for GitLab, with different scoping:

OAuth application (team-level, self-managed only)

One team admin registers an OAuth application in their self-managed GitLab instance. The application's credentials (client ID and client secret) are stored at the Miro team level, encrypted. Every member of that Miro team can see the OAuth app card and authorize their own account through it, but each user's resulting access token is still stored per user and cannot be used by anyone else.

The admin who created the OAuth app can revoke it at any time (see Revoke access below). Only that user has the Remove App control.

GitLab.com OAuth (per-user)

For GitLab.com connections, each user completes a standard OAuth authorization flow. Their individual access and refresh tokens are stored per-user and encrypted.

Revoke access

How to revoke access to any connection method.

Revoke a GitLab.com OAuth connection

In the GitLab for Miro panel, open Connections.
Find the connection and click Remove.
Confirm the removal. The app deletes the stored tokens.
To fully revoke at the GitLab level: in GitLab, go to User Settings > Applications (or /-/profile/applications), find the "GitLab for Miro" application, and click Revoke.

Revoke a Personal Access Token

In the GitLab for Miro panel, open Connections.
Click Remove on the PAT connection and confirm.
To revoke the token in GitLab: go to User Settings > Personal Access Tokens (or /-/user_settings/personal_access_tokens), find the token, and click Revoke from the overflow menu.

Remove a self-managed OAuth application (admin)

In the GitLab for Miro panel, open Connections.
The OAuth app card shows a Remove App button only for the user who created it.
Click Remove App and type delete in the confirmation field to confirm.
To fully remove it from GitLab: in your GitLab instance, go to Admin Area > Applications, find the application, and click Destroy.
Warning: Removing the OAuth app in the GitLab for Miro panel also disconnects all team members who authorized through it. They will need to reconnect once a new OAuth app is configured, or switch to Personal Access Tokens.

Self-managed instance requirements

Details on the requirements for the app to work with self-managed GitLab instances.

For the app to work with a self-managed GitLab instance, the following must be true:

The GitLab instance must be reachable from the public internet via HTTPS. The app's Lambda backend (AWS, us-east-1) makes server-side API calls to the instance URL you configure. Instances accessible only over a VPN or private network are not supported.
The instance URL must use https://. Plain http:// is not accepted.
The OAuth or PAT credentials must have the api and read_api scopes granted.

There is no agent or on-premises component to install. All communication is outbound from the app's AWS backend to your GitLab instance.