Security and Consent
This page is written for Microsoft 365 and Entra administrators who need to decide whether OSO MS Teams CLI is acceptable in their tenant.
The short version:
- The default OSO app is a Microsoft Entra multi-tenant public client app.
- It uses delegated Microsoft Graph permissions, not an OSO-owned service account.
- Messages and reads happen as the signed-in Microsoft 365 user.
- The CLI calls Microsoft Graph directly from the machine where it runs.
- Tokens are stored locally in the OS credential store for the selected profile.
- OSO cannot access your tenant just because you grant consent to the app.
- Tenant admins can restrict, monitor, or revoke access through Entra enterprise application controls.
Default app identity
The default app used by teams auth login is:
| Field | Value |
|---|---|
| Display name | OSO Teams CLI |
| Public client ID | fba1b5d0-fdd0-4fe2-9729-9ccdc38f9595 |
| Authority | organizations |
| Sign-in audience | Work and school accounts in any Microsoft Entra tenant |
| Redirect URI | http://localhost:8400/callback |
| Publisher domain | oso.sh |
| Homepage | http://msteamscli.com/ |
| Privacy policy | https://oso.sh/privacy-policy/ |
| Support | https://oso.sh/contact/ |
The client ID is public. It is not a secret and does not grant access by itself.
Why there is no client secret
OSO MS Teams CLI is a command-line app installed on user machines and CI runners. That makes it a public client in Microsoft identity terminology. Public clients cannot safely keep a client secret, because anything embedded in a binary or script can be extracted.
Security comes from Microsoft sign-in, Conditional Access, delegated consent, the signed-in user's permissions, local token storage, and tenant policy.
What consent allows
Consent authorizes the app to request Microsoft Graph tokens for approved delegated scopes. Delegated means the app acts on behalf of the signed-in user.
Consent does not give OSO a password, client secret, tenant secret, Graph token, or background connection into the tenant.
After consent, a user still has to sign in. Commands then use the resulting token to call Microsoft Graph from the local CLI process.
What OSO can and cannot access
OSO can:
- Publish and operate the app registration.
- Define the Graph delegated scopes that the app requests.
- Provide software and support.
OSO cannot, from the CLI-only app registration alone:
- Read Teams messages in your tenant.
- Send Teams messages in your tenant.
- Retrieve your users' access or refresh tokens.
- Bypass your tenant's Conditional Access policies.
- Run commands on your users' machines.
The operator, automation, or agent running the CLI can access data allowed by the signed-in user's token and the consented scopes. Treat any machine or agent with a signed-in teams profile as having the corresponding delegated access.
Current delegated scopes
The OSO app currently requests these delegated Microsoft Graph scopes:
| Scope | Why it is requested | Security note |
|---|---|---|
User.Read | Sign in and read the signed-in user's basic profile. | Low baseline sign-in scope. |
offline_access | Store refresh capability so users do not have to sign in for every command. | Produces refresh tokens; protect the endpoint credential store. |
Team.ReadBasic.All | List teams the CLI can work with. | Tenant policy and Graph behavior still apply. |
Channel.ReadBasic.All | List channels for selected teams. | Required before channel message operations. |
ChannelMessage.Send | Send channel messages as the signed-in user. | Messages appear as that user. |
ChannelMessage.Read.All | Read channel messages for channel workflows. | High-impact scope; requires admin review and tenant-wide trust. |
Chat.ReadWrite | Work with chat objects and chat workflows. | High-impact delegated chat access. |
ChatMessage.Read | Read chat messages for accessible chat workflows. | Meeting or restricted chats can still deny reads. |
ChatMessage.Send | Send chat messages as the signed-in user. | Messages appear as that user. |
User.ReadBasic.All | Resolve users for member and mention workflows. | Exposes basic directory profile data through Graph. |
Presence.Read.All | Read user presence for presence commands. | Tenant policy can restrict presence access. |
Some Microsoft Graph permission labels are broad. Admins should review the consent prompt and the enterprise application permissions before granting tenant-wide consent.
File commands may require additional Microsoft Graph file permissions in some tenants or future releases. If your tenant does not want those permissions on the shared OSO app, use a customer-owned app registration and grant only the permissions your rollout needs.
Admin consent flow
Generate the consent URL for your tenant:
teams auth consent-url --tenant-id <tenant-id-or-domain> --output json
The URL has this shape:
https://login.microsoftonline.com/<tenant>/adminconsent?client_id=fba1b5d0-fdd0-4fe2-9729-9ccdc38f9595
Before approving:
- Confirm the app name is
OSO Teams CLI. - Confirm the client ID matches the value above.
- Review every requested Microsoft Graph permission.
- Confirm the publisher identity is the expected OSO publisher.
- Use a pilot group before broad rollout.
For production tenants, require the Microsoft consent prompt to show the expected OSO publisher details. If your policy requires publisher verification and the prompt does not show the verified publisher signal yet, use a customer-owned app registration or wait for verification to be complete.
BYO Entra app option
Use a customer-owned app registration when:
- Your tenant blocks third-party multi-tenant apps.
- You need to approve a smaller scope set.
- You require internal ownership, naming, branding, or lifecycle control.
- You want consent, sign-in logs, and risk reviews tied only to your own app object.
Minimum BYO configuration:
- App type: public client/native app.
- Redirect URI:
http://localhost:8400/callback. - Supported account type: single tenant or multi-tenant, depending on your rollout.
- Delegated Microsoft Graph permissions matching the commands you will allow.
- Admin consent granted by the tenant administrator where required.
Login with a customer app:
teams auth login --device-code --client-id <customer-client-id> --tenant-id <tenant-id>
Token storage
The CLI stores tokens in the operating system credential store where supported:
| Platform | Expected storage |
|---|---|
| macOS | Keychain |
| Windows | Windows Credential Manager |
| Linux | Secret Service/libsecret compatible keyring |
Config files store non-secret identifiers such as profile name, client ID, tenant ID, output preference, and auth mode. They should not contain access tokens or refresh tokens.
The environment variable TEAMS_CLI_ACCESS_TOKEN bypasses the keyring for that process. Use it only in controlled automation where the token source and logs are protected.
Revocation and tenant controls
Admins can control the app from Microsoft Entra:
- Review sign-ins for the enterprise application.
- Revoke admin consent for the app's Graph permissions.
- Disable or delete the enterprise application service principal.
- Restrict user consent and require admin approval workflow.
- Apply Conditional Access policies such as MFA, compliant device, sign-in risk, and sign-in frequency.
- Block or allow device-code flow according to tenant policy.
Users can remove local credentials with:
teams auth logout
teams auth logout --all
Local logout removes stored CLI tokens. Tenant-side revocation should still be done in Entra when access must be blocked centrally.
Teams Store and marketplace
The current product is a CLI that uses Microsoft Graph. It is not a Teams app, bot, tab, or message extension. A Teams Store or AppSource listing is not required for the CLI to authenticate as a multi-tenant Entra public client.
Teams Store, Microsoft 365 app certification, publisher attestation, or a Teams app package become relevant if OSO ships a Teams app or bot experience.
Security review checklist
Before approving production use:
- Confirm the app identity and client ID.
- Review the exact delegated Graph scopes.
- Decide whether the OSO shared app or BYO app is the right control model.
- Pilot with a dedicated team/channel and non-sensitive data.
- Validate Conditional Access behavior.
- Confirm token storage on each supported OS.
- Restrict which agents or CI jobs can run write commands.
- Document how to revoke tenant consent and local tokens.