Product: Awair Dashboard
Note: Awair Business Dashboard is only compatible with Awair Business App and must be activated internally before you can access it. If you’re interested in setting up an Awair Business account with us, please click here to get in touch with our sales team.
Overview
This article describes the authentication options for logging into the Awair Dashboard, and how this is affected by the enforcement of Single Sign-On (SSO).
It also explains:
- The current login flow
- The rationale behind the proposed change
- The path forward to align with enterprise SSO best practices
Architecture Summary
Awair supports a multi-organization model, where a single organization (Dashboard account) may operate independently, or it may belong to another organization. Authentication methods include:
- Standard authentication (email/password or social login)
- Enforced SSO (via enterprise identity provider)
To support this, Awair uses a two-layer authentication model:
Layer 1 – Global Authentication (Session Initialization)
Users can select an option to authenticate, implemented via Google Identity Platform.
Purpose:
- Establish a user session
- Support multiple login methods (Google, Microsoft, email/password)
- Enable users to access multiple organizations within a single account
⚠️ Important:
This step does not grant access to any organization data
Layer 2 – Organization-Level Authentication (SSO Enforcement)
Specifically for accounts that require SSO, users must authenticate via the organization’s configured IdP (e.g. Microsoft Entra ID). This is implemented via a private enterprise application configured by the customer
Purpose:
- Enforce organization-specific access control
- Validate user identity via the customer’s identity provider
- Retrieve identity claims (e.g. email, name)
Authentication Flow
Step 1 – User Login
User signs in via Google / Microsoft account or email/password (via Google Identity Platform)
→ A session is created
→ No organization access is granted at this stage
Step 2 – Organization Selection
User selects the organization they want to access
Step 3 – Policy Enforcement
If SSO is NOT required
→ Access is granted
If SSO IS required
→ User is redirected to authenticate via Microsoft Entra ID
→ Access is granted only after successful SSO authentication
Security Model
Awair data is protected by organization-level policy enforcement
For SSO-enabled organizations:
- Authentication via the IdP is mandatory
- The initial login step alone is insufficient to gain access
Identity and access decisions rely on:
- SSO assertions (OIDC)
- Organization membership within Awair
Microsoft Permissions & Admin Consent
A potential solution was proposed to request admin consent for a separate enterprise application in Microsoft Entra ID with the following delegated Microsoft Graph permissions:
- User.Read
- offline_access
This approach was introduced to address issues with user provisioning and account linking for newly onboarded users. The requested permissions would allow Awair to:
- Retrieve basic user profile information (e.g. email, unique identifier)
- Improve reliability of user provisioning and identity matching
Organizations may see a one-time admin consent request when accessing Awair via Microsoft Entra ID. To approve this, you must:
1. Go to Microsoft Entra admin center
2. Navigate to Enterprise Applications
3. Search for Awair or Client ID: f5312d16-9def-423d-8dac-406e15c05d46
4. Open the application → Permissions
5. Click “Grant admin consent”
Please note: This is a one-time administrative action, and permissions are limited to the signed-in user. SSO via Microsoft Entra ID remains the authoritative authentication mechanism. The consent request is not intended to replace or bypass SSO
Summary
Awair supports both standard authentication and SSO-based authentication depending on Organization policy. For SSO-enabled organizations, Microsoft Entra ID is the authoritative identity provider. The global authentication layer is used only for session initialization and multi-organization support. The admin consent request is a standard, one-time step required to enable secure integration with Microsoft identity services. The requested permissions are minimal and scoped to support authentication and user identity.