# Consent, grants and data sharing > What a customer consents to, managing connected apps, and choosing which data to share. > **Preview / beta** > > The Application Marketplace is under active development and may change without long deprecation windows. See the [Application Marketplace overview](/docs/platform/integrations/marketplace). OAuth approves *scopes*: what kinds of thing an application may do. For applications that read charging data, the customer separately chooses *which resources* the application may see. The two are deliberately decoupled, so a customer can change what they share without re-running OAuth. ## What the user consents to On the consent screen the customer sees the application and the scopes it has requested. The scopes Road supports are deliberately small and coarse: | Scope | What it grants | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `openid` | OIDC marker; an ID token is issued and the basic account identifier (subject, account, provider) is available. | | `offline_access` | A refresh token, so the application can act while the user is offline. | | `profile` | The user's name and profile attributes. | | `email` | The user's email address. | | `account:read` | Read the user's own account details (name and contact). | | `account:billing:read` | Read the account's billing details (`billing`, `creditBilling`). Also requires the user's billing permission, so an application cannot read billing just because the user is an account admin. | | `ere` | Read the user's ERE charging data (sessions and charging-station metadata) through the [ERE API](/docs/platform/charge-point-operation/ere-integration). Subject to data sharing (below). A [gated scope](/docs/platform/integrations/marketplace/registration): available to curated templates and provider installations only. | | `chargers:read` | Read the user's charging-station metadata. Subject to data sharing (below). | | `sessions:read` | Read the user's charging sessions (CDRs). Subject to data sharing (below). | The consent screen groups these for clarity (account information, charging data, ongoing access). `openid` is the OIDC marker scope: it grants the basic account identifier, not identity verification. The user approves a subset and a grant is recorded for them. ## Grants are per user Each grant authorises one application for one user, recording the scopes that user approved. It is the runtime authority for that user's tokens. Revoking it disconnects the application for that user only; other users keep their own grants. ## Managing connected applications A customer manages their own connections at **Settings → Personal → Connected apps**. From there they can: - See which applications are connected and what each can access. - Revoke an application, which immediately stops its access for that user. - Adjust what a charging-data application can see (the data-sharing selection, below). ## Narrowing access after the grant Access can be reduced after consent without the user re-authorising: - A **provider administrator** can edit the application's scopes (or revoke the installation) from **My Locations → Integrations → Apps**. Tightening the installation reduces what every connected user's tokens can do; tokens still claiming a removed scope are rejected until refreshed, and the refreshed token no longer carries it. - A **user** can revoke their grant or narrow their data-sharing selection at any time. In all cases the change takes effect on the next request; existing tokens do not need to expire first. How an application observes these changes is covered in [Using the API](/docs/platform/integrations/marketplace/using-the-api). ## Choosing which data to share Scopes say an application may read charging data; they do not say *whose* charging stations and sessions. For the charging-data scopes (`ere`, `chargers:read`, `sessions:read`) the customer makes a separate, explicit choice of which resources to share. ### When the data-sharing step appears The data-sharing step is shown only when the requested scopes unlock a shareable resource family. Today that is the charging-data scopes (`ere`, `chargers:read`, `sessions:read`). Applications that request only account scopes (`openid`, `email`, `profile`, `account:read`, `account:billing:read`, `offline_access`) never see a sharing step; scope consent alone is enough. ### What a user can share The customer shares at the level of **locations** and/or individual **EVSEs**. They can either: - share everything they are currently eligible for, or - select specific locations and/or EVSEs. A location selection expands to the EVSEs under it. ### Eligibility What a customer may share follows the same access rules as their "My Locations" view: - A regular user can share the locations and EVSEs they own. - An account administrator can share any location or EVSE in the account. A customer can only ever select resources they currently have access to. Any read-time ownership rules specific to a particular data surface (for example ERE, which only ever returns a user's own charging stations) are applied by that surface on top of the share; see [ERE integration](/docs/platform/charge-point-operation/ere-integration). ## Adjusting sharing at any time The data-sharing selection is stored independently of the OAuth grant, keyed to the installed application. The customer can change or revoke it at any time from **Settings → Personal → Connected apps** without re-running OAuth. If an application holds a data scope but the customer has shared nothing, the scoped data endpoints simply return an empty list; the grant stays valid. For how an application reads that data, see [Using the API](/docs/platform/integrations/marketplace/using-the-api) and [ERE integration](/docs/platform/charge-point-operation/ere-integration).