Problem
The default aware connect flow is browser token-paste — the user must hand-obtain a raw access token (e.g. Graph Explorer, OAuth Playground) and paste it. That's a developer workflow, not viable for real end users:
- Org users can't generate raw tokens. Privileged Graph/Google scopes need admin consent; managed tenants block dev tools and raw token extraction via Conditional Access.
- Paste tokens have no refresh token — they die in ~1 hour, so even when they work it's not durable.
- Scope-limited — a hand-grabbed token rarely carries exactly the scopes a workflow needs (Files.ReadWrite, Sites.ReadWrite, ChannelMessage.Send, Mail.Send, …).
--oauth and --device-code are the right flows (normal company sign-in, refresh tokens), but they require a registered OAuth application:
--oauth needs AWARE_OAUTH_<INTEGRATION>_CLIENT_ID — undocumented how a user obtains one.--device-code (RFC 8628) also needs a registered public client.
There's no shipped app, so neither works out of the box for an end user.
Ask
Register and ship first-party OAuth apps so aware connect microsoft-365 --device-code (and Google / Trimble equivalents) work with zero setup:
- Register a multi-tenant Azure AD app (M365), a Google Cloud OAuth client (Workspace), and a Trimble app with the delegated scopes the curated agents need.
- Bundle the client IDs with the CLI (or fetch from the registry) so
--device-code/--oauth have a client ID without the user setting env vars.
- Document the admin-consent step (one-time per tenant) for privileged scopes.
- Make
--device-code the recommended default on Windows / managed tenants.
Dependency
Blocked by #139 — even with a registered app, --device-code/--oauth persist access + refresh tokens through the same Windows keyring path that #139 rejects. Both must land for real cloud auth on Windows.
Why it matters
This is the difference between "demo with a hand-pasted 1-hour token" and "an AEC engineer signs in with their company account once." It's the gate for every cloud workflow (college-phase-exporter's Excel/Teams/email/Trimble steps, the Supabase/HTTP cases) being real for actual users.
Problem
The default
aware connectflow is browser token-paste — the user must hand-obtain a raw access token (e.g. Graph Explorer, OAuth Playground) and paste it. That's a developer workflow, not viable for real end users:--oauthand--device-codeare the right flows (normal company sign-in, refresh tokens), but they require a registered OAuth application:--oauthneedsAWARE_OAUTH_<INTEGRATION>_CLIENT_ID— undocumented how a user obtains one.--device-code(RFC 8628) also needs a registered public client.There's no shipped app, so neither works out of the box for an end user.
Ask
Register and ship first-party OAuth apps so
aware connect microsoft-365 --device-code(and Google / Trimble equivalents) work with zero setup:--device-code/--oauthhave a client ID without the user setting env vars.--device-codethe recommended default on Windows / managed tenants.Dependency
Blocked by #139 — even with a registered app,
--device-code/--oauthpersist access + refresh tokens through the same Windows keyring path that #139 rejects. Both must land for real cloud auth on Windows.Why it matters
This is the difference between "demo with a hand-pasted 1-hour token" and "an AEC engineer signs in with their company account once." It's the gate for every cloud workflow (college-phase-exporter's Excel/Teams/email/Trimble steps, the Supabase/HTTP cases) being real for actual users.