O Single Sign-On (SSO) permite que os utilizadores acedam a múltiplas aplicações com uma única autenticação — entram uma vez com as credenciais da organização e acedem a todas as ferramentas sem voltar a introduzir password. No ecossistema Microsoft, o SSO é gerido pelo Microsoft Entra ID e está disponível em diferentes níveis consoante o licenciamento.
A confusão mais comum: muitas organizações têm SSO parcialmente funcional sem o saber (as aplicações Microsoft 365 já usam SSO nativo), mas para aplicações de terceiros — Salesforce, Zendesk, Jira, Zoom, HubSpot — é necessário configuração explícita e, em alguns casos, licenciamento adicional.
ℹ SSO não é o mesmo que password partilhada
Algumas aplicações mais antigas oferecem SSO baseado em password vaulting — o Entra ID guarda a password e preenche automaticamente. Não é SSO real: a aplicação ainda valida por password. O SSO verdadeiro via SAML ou OIDC elimina completamente a password na aplicação — o token do Entra ID é a única credencial válida.
Neste artigo
- Como funciona o SSO com Entra ID
- Licenciamento — o que está incluído em cada plano
- Protocolos SSO — SAML, OIDC e OAuth 2.0
- Configurar SSO para aplicações da galeria Entra ID
- Configurar SSO para aplicações personalizadas
- Seamless SSO — ambientes híbridos com AD on-premises
- Provisionamento automático de utilizadores (SCIM)
- SSO em conjunto com Conditional Access
- Armadilhas comuns e resolução de problemas
- PowerShell — gerir aplicações SSO no Entra ID
1. Como funciona o SSO com Entra ID
No modelo SSO com Entra ID, a autenticação tem três intervenientes: o utilizador, o Entra ID (Identity Provider — IdP) e a aplicação (Service Provider — SP). O utilizador nunca introduz a sua password directamente na aplicação — autentica-se no Entra ID, que emite um token que a aplicação aceita.
| Passo | O que acontece | Interveniente |
|---|---|---|
| 1 | Utilizador tenta aceder à aplicação (ex: Salesforce) | Utilizador → Aplicação |
| 2 | A aplicação redireciona para o Entra ID para autenticação | Aplicação → Entra ID |
| 3 | Utilizador autentica-se no Entra ID (login M365 + MFA se configurado) | Utilizador → Entra ID |
| 4 | Entra ID emite um token (SAML assertion ou JWT) e devolve ao browser | Entra ID → Browser |
| 5 | Browser apresenta o token à aplicação — acesso concedido sem nova password | Browser → Aplicação |
2. Licenciamento — o que está incluído em cada plano
O SSO com Entra ID tem capacidades diferentes consoante o nível de licença. A distinção mais importante é entre o plano Free (incluído em qualquer subscrição M365) e os planos pagos P1 e P2.
| Capacidade SSO | Entra ID Free | Entra ID P1 | Entra ID P2 |
|---|---|---|---|
| SSO nativo para apps Microsoft 365 (Teams, SharePoint, Exchange, etc.) | ✓ | ✓ | ✓ |
| SSO para apps da galeria Entra ID (SAML/OIDC) — limite de 10 apps | 10 apps | Ilimitado | Ilimitado |
| SSO para apps fora da galeria (aplicações personalizadas) | ✗ | ✓ | ✓ |
| Conditional Access (restringir acesso SSO por condição) | ✗ | ✓ | ✓ |
| Provisionamento automático de utilizadores (SCIM) | ✗ | ✓ | ✓ |
| Seamless SSO (Hybrid — AD on-premises) | ✓ | ✓ | ✓ |
| Identity Protection (risco de login, acesso condicional baseado em risco) | ✗ | ✗ | ✓ |
Onde o P1 está incluído nos planos M365:
- Microsoft 365 Business Premium — inclui Entra ID P1 ✓
- Microsoft 365 E3 — inclui Entra ID P1 ✓
- Microsoft 365 E5 — inclui Entra ID P2 ✓
- Business Basic / Standard — apenas Entra ID Free (limite de 10 apps SSO)
- Entra ID P1 disponível como add-on standalone: $6/utilizador/mês
3. Protocolos SSO — SAML, OIDC e OAuth 2.0
O Entra ID suporta múltiplos protocolos de SSO. A escolha depende do que a aplicação de destino suporta — na prática, a aplicação determina o protocolo.
| Protocolo | Token | Típico em | Complexidade |
|---|---|---|---|
| SAML 2.0 | XML (SAML Assertion) | Apps empresariais legadas e SaaS — Salesforce, Zendesk, Jira, AWS, ServiceNow | Média — troca de metadados XML |
| OpenID Connect (OIDC) | JWT (JSON Web Token) | Apps modernas cloud-native — GitHub, Slack, Zoom, HubSpot, apps web próprias | Baixa — Client ID e Secret |
| OAuth 2.0 | Access Token (JWT) | APIs e apps que precisam de aceder a recursos — base do OIDC | Baixa a média |
| Password-based SSO | Nenhum — vaulting | Apps sem suporte SAML/OIDC — preenchimento automático do formulário de login | Não recomendado — não é SSO real |
ℹ Como escolher o protocolo: A aplicação de destino determina a escolha. Se suportar ambos SAML e OIDC, preferir OIDC para apps novas — mais simples e adequado para cloud. Usar SAML quando a app é mais antiga ou o guia do fornecedor indica especificamente SAML.
4. Configurar SSO para aplicações da galeria Entra ID
A galeria do Entra ID tem mais de 3 000 aplicações pré-configuradas. O processo resume-se a: adicionar a app ao tenant, configurar os identificadores, atribuir utilizadores e activar o SSO na aplicação de destino.
Caminho: entra.microsoft.com → Applications → Enterprise applications → New application → [pesquisar app]
- Adicionar a app da galeria → Create
- Menu da aplicação → Single sign-on → SAML
- Preencher a Secção 1 — Basic SAML Configuration: Identifier (Entity ID) e Reply URL (ACS URL) — valores fornecidos pelo fornecedor da app
- Secção 3 — fazer download do Certificate (Base64) e da Federation Metadata XML — a app precisa destes para validar os tokens do Entra ID
- Secção 4 — copiar o Login URL e o Azure AD Identifier para configurar na aplicação de destino
- Secção 2 — verificar Attributes & Claims (nome, email, grupos) — ajustar conforme a app exige
- Users and groups → adicionar os utilizadores ou grupos com acesso
- Testar com o botão Test na página de configuração
⚠ Atribuição obrigatória: Por defeito, utilizadores não atribuídos recebem erro de acesso ao tentar o SSO. Em Properties da aplicação, o campo Assignment required controla este comportamento. Manter em Yes para apps críticas.
5. Configurar SSO para aplicações personalizadas (fora da galeria)
Para aplicações desenvolvidas internamente ou fora da galeria, usar “Create your own application”. Requer Entra ID P1 (incluído em Business Premium, E3, E5).
Caminho: entra.microsoft.com → Enterprise applications → New application → Create your own application
Connect-MgGraph -Scopes "Application.ReadWrite.All" # Criar registo de aplicação OIDC $app = New-MgApplication -DisplayName "App Interna SSO" ` -SignInAudience "AzureADMyOrg" ` -Web @{RedirectUris = @("https://appinterna.empresa.pt/auth/callback")} Write-Host "Client ID: $($app.AppId)" # Criar Client Secret (guardar o valor — só visível uma vez) $secret = Add-MgApplicationPassword -ApplicationId $app.Id ` -PasswordCredential @{DisplayName="SSO Secret"; EndDateTime=(Get-Date).AddYears(2)} Write-Host "Client Secret: $($secret.SecretText)" # Endpoints OIDC para configurar na aplicação $tenantId = (Get-MgOrganization).Id Write-Host "Authority: https://login.microsoftonline.com/$tenantId/v2.0" Write-Host "Token Endpoint: https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
| Parâmetro na app | Valor do Entra ID |
|---|---|
| Client ID | AppId do registo (GUID) — visível em App registrations |
| Client Secret | Criado em Certificates & secrets — guardar no momento da criação |
| Authority URL | https://login.microsoftonline.com/{tenant-id}/v2.0 |
| Token Endpoint | https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token |
| Redirect URI | URL de callback da app — registado em App registrations → Authentication |
6. Seamless SSO — ambientes híbridos com AD on-premises
Em organizações com AD on-premises e Entra ID (ambiente híbrido com Entra Connect), o Azure AD Seamless SSO permite que utilizadores em PCs ligados ao domínio acedam a recursos cloud sem introduzir password — a autenticação Kerberos do domínio é usada automaticamente.
- No servidor Entra Connect: abrir o assistente → Change user sign-in
- Activar Enable single sign-on
- Introduzir credenciais de Domain Admin
- O Entra Connect cria a conta
AZUREADSSOACCno AD — usada para desencriptar tickets Kerberos
# Verificar conta AZUREADSSOACC no AD Get-ADComputer -Identity "AZUREADSSOACC" -Properties Created, PasswordLastSet # Browsers precisam do URL de autologon na zona Intranet — configurar via GPO: # Adicionar a zona Intranet: https://autologon.microsoftazuread-sso.com # Verificar estado do Seamless SSO no PC do utilizador dsregcmd /status # Confirmar: AzureAdJoined=YES, DomainJoined=YES, SsoState=VIA SSO TICKET
7. Provisionamento automático de utilizadores (SCIM)
O SSO resolve a autenticação — mas os utilizadores têm de existir na aplicação de destino. O SCIM sincroniza automaticamente utilizadores e grupos do Entra ID para a app, criando e desactivando contas em tempo real. Requer Entra ID P1.
Caminho: Enterprise applications → [app] → Provisioning → Automatic
- Provisioning Mode: Automatic
- Admin Credentials — URL do endpoint SCIM da app e token de autenticação
- Clicar Test Connection para confirmar conectividade
- Verificar Mappings — como os atributos Entra ID mapeiam para os da app
- Definir Scope — utilizadores/grupos atribuídos ou todos
- Activar e monitorizar em Provisioning logs
✓ SSO + SCIM — o fluxo ideal: SCIM cria o utilizador na app quando é adicionado ao Entra ID. SSO garante autenticação via Entra ID sem password separada. Quando o utilizador sai e a conta Entra ID é desactivada, o SCIM desactiva automaticamente a conta na app — zero risco de acesso residual após offboarding.
8. SSO em conjunto com Conditional Access
O SSO sozinho não é suficiente para segurança empresarial — autentica, mas não verifica o contexto. O Conditional Access (Entra ID P1) adiciona condições ao acesso SSO.
| Política CA útil para SSO | O que faz | Quando usar |
|---|---|---|
| Exigir MFA para app específica | Exige MFA adicional ao aceder via SSO a apps de alto risco, mesmo com sessão activa | ERP, sistemas financeiros, dados sensíveis |
| Exigir dispositivo Intune-compliant | Só permite SSO se o dispositivo está registado no Intune e em conformidade | Impedir acesso via dispositivos BYOD não geridos |
| Bloquear acesso fora de Portugal | Bloqueia SSO quando o IP de acesso não é português (Named Locations) | Apps que não devem ser acedidas internacionalmente |
| Session Lifetime Control | Força re-autenticação após X horas mesmo com SSO activo | Apps críticas onde sessões eternas são inaceitáveis |
9. Armadilhas comuns e resolução de problemas
| Problema | Causa | Resolução |
|---|---|---|
| AADSTS50105 — user not assigned | Utilizador não adicionado em Users and groups da Enterprise Application | Enterprise applications → [app] → Users and groups → adicionar utilizador/grupo |
| SSO funciona no browser mas não na app desktop | Redirect URI da app desktop não registado no Entra ID | App registrations → Authentication → adicionar o redirect URI correcto |
| SAML Signature validation failed | Certificado SAML renovado mas não actualizado na aplicação | Download do novo certificado em SAML Certificates e actualizar na app |
| Seamless SSO não funciona — browser pede password | URL autologon não está na zona Intranet, ou PC não está em Hybrid Join | Verificar GPO da zona Intranet. Confirmar Hybrid Join: dsregcmd /status |
| Client Secret expirado — SSO falha subitamente | Secret atingiu a data de expiração sem aviso | App registrations → Certificates & secrets → New client secret → actualizar na app |
| Atributo em falta no token SAML | App requer claim específico (role, departamento) não configurado | Enterprise applications → [app] → Single sign-on → Attributes & Claims → adicionar o claim em falta |
10. PowerShell — gerir aplicações SSO no Entra ID
Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All" # Listar todas as Enterprise Applications com SSO configurado Get-MgServicePrincipal -All -Filter "PreferredSingleSignOnMode ne null" | Select-Object DisplayName, PreferredSingleSignOnMode, AppId | Format-Table -AutoSize # Utilizadores atribuídos a uma Enterprise Application específica $spId = (Get-MgServicePrincipal -Filter "DisplayName eq 'Salesforce'").Id Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $spId | Select-Object PrincipalDisplayName, PrincipalType | Format-Table -AutoSize # App Registrations com Client Secrets a expirar nos próximos 30 dias Get-MgApplication -All | ForEach-Object { $app = $_ $_.PasswordCredentials | Where-Object { $_.EndDateTime -lt (Get-Date).AddDays(30) -and $_.EndDateTime -gt (Get-Date) } | ForEach-Object { [PSCustomObject]@{ App = $app.DisplayName Secret = $_.DisplayName Expira = $_.EndDateTime DiasRestantes = ($_.EndDateTime - (Get-Date)).Days } } } | Sort-Object DiasRestantes | Format-Table -AutoSize
⚠ Monitorizar expirações de Client Secrets: Os secrets expiram silenciosamente (máximo 24 meses). Quando expiram, o SSO falha subitamente sem aviso ao utilizador. Executar o script acima mensalmente ou activar alertas em: entra.microsoft.com → Applications → App registrations → expiring credentials.
