Entra ID provides authentication via SAML, OpenID Connect, and OAuth 2.0. This page covers topics related to user authentication with Entra ID. For more on application integration with Entra ID, see Entra ID Applications.
UW’s Entra ID is integrated with the UW NetID system. If your UW NetID is “pottery” then your Entra ID username is pottery@uw.edu. This longer form is called the user principal name or UPN. Every cloud-based experience will require this longer form because cloud-providers can not assume you are from the UW, like the UW identity provider can.
Your Entra ID user account is provisioned based on its status in the NETID Active Directory; if it is inactive, disabled or deleted there, it will not exist in the UW Entra ID .
At this time, the uw.edu Entra ID domain is federated.
The uw.edu Entra ID domain uses UW NetID passwords in the form of Microsoft calls password hashes. This jargon just means your password is not actually present in Microsoft’s cloud-based Entra ID , but a derived form of it which can be used to verify whether the password you provide to prompts is correct.
When signing in, after you’ve entered the user principal name (e.g. uwnetid@uw.edu) , Microsoft first checks to see what type of account it is, and whether there are multiple types of accounts with that user principal name (UPN. If there are multiple types of accounts with that same username, it asks whether the account is a work/school account or a personal account. In almost all cases, you should chooose work/school account. See here for more info.
We recommend that users opt into the Duo 2FA for Web.
You will have one of two sign-in experience based on whether your account is configured to require Duo 2FA:
Entra ID allows users from other organization’s Entra ID tenants and personal Microsoft Accounts to be guest users in your Entra ID tenant. These guest users are called External Users. Once an external user is present in your Entra ID tenant, they can be permitted access to resources in our Entra ID tenant. Entra ID Conditional Access policies can be applied to external users. Leveraging some of these other capabilities may require additional licensing, so there may be a cost associated.
Within the uw.edu Entra ID enterprise tenant, we allow any user in the tenant to invite external users. The UW disables inactive guest users from its tenant after 180 days of inactivity, with deletion 30 days later. Guests whose account in the UW tenant is deleted should ask the relevant UW party to re-invite them. Additionally, the person in control of an external user account can deprovision those accounts in other Entra ID tenants by themselves. In the future, as Microsoft develops the management capabilities for external users, there may be additional restrictions or limitations the UW imposes.
Your uw.edu Entra ID account may be an external user in another organization’s Entra ID . You can tell whether it is or not by going to https://myworkaccount.microsoft.com/organizations. You can remove your external user account in those other organizations via that same interface.
Your Entra ID sign ins are logged and you can review them. There are two locations you can go.
- My Sign-Ins – simplified list of your UW Entra ID sign-ins
- Azure Portal – Once here, enter your username, select your account, then choose “Sign-Ins” under Activity. This interface contains detailed information about your sign-ins. By default it will show the past 24 hours, but you can go up to 30 days in the past.
Note: you can only review your own sign-in details.
Unlike the UW identity provider, Microsoft’s Entra ID product has authentication tokens with long lifetimes. Microsoft’s design reflects their extensive experience and analysis of the impact of token lifetime on overall security and the user experience. Microsoft has found that binding your Entra ID authentication token to a device with a lengthy default token lifetime paired with token revocation events that are triggered when something risky is detected result in the best security and user experience. To be clear, Microsoft has found that requiring users to sign-in frequently causes users to grow fatigued about entering their credentials and therefore be more easily fooled by malicious phishing attempts.
For this reason, the UW Duo ‘remember me’ guidance doesn’t have meaning for Entra ID ; an Entra ID identity token essentially lives forever unless something happens to require a fresh sign-in.
An Entra ID access token (constrained to the Entra ID application) is obtained when the user wants to access an application which uses Entra ID for authentication. Entra ID access tokens do not live forever. By default Entra ID access tokens have a 1 hour lifetime, but can be anywhere from 10 minutes to 1 day. By default, the application developer controls the lifetime of its access tokens. For more information about token lifetimes, see https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes#configurable-token-lifetime-properties.
When misuse is detected on a uw.edu Entra ID user account, all of that account’s tokens are revoked and an Entra ID Conditional Access policy blocks issuance of any new Entra ID access tokens until the account can be returned to service. For more information about token revocation, see https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens#token-revocation.
For token lifetime, there is also an administrative control called authentication session management, by which Entra ID Conditional Access (CA) is used to control the lifetime of identity and access tokens which meet the specific conditions in the CA policy configured. UW can configure a CA policy upon request, but Conditional Access can lead to significant unexpected impacts, so we have to exercise judicious vetting and practices to prevent undesirable outcomes. Also note that many of the CA conditions possible may not be viable.
For more info about Entra ID tokens, see https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token.
Entra ID provides the OAuth 2.0 protocol which supports the ability for one application to get an access token on your behalf to another application. This ability generally requires your consent or the organization’s consent. Microsoft describes the consent experience with Entra ID here: https://docs.microsoft.com/en-us/azure/active-directory/develop/application-consent-experience.
You can review which applications have some consent to act on your behalf at https://portal.office.com/account/?ref=MeControl#apps. Note that the top section are applications which you have explicitly granted consent and which you can revoke at any time. The bottom section are applications with implicitly granted permission scopes as a consequence of license subscriptions or admin roles you have been granted–you can’t revoke these directly.
Conditional Access (CA) is a powerful feature that allows security controls to be enforced at the time an access token is requested based on a variety of conditions. UW support for Conditional Access is limited at this time. If you feel you need a CA policy, send a request and we’ll consider it.
Conditional Access can lead to significant unexpected impacts, so we have to exercise judicious vetting and practices to prevent undesirable outcomes. Also note that many of the CA conditions possible may not be viable.
“Legacy authentication” is a term Microsoft sometimes uses to describe basic authentication when used with its cloud-based services. This is in contrast with the term “modern authentication” which provides more security and capabilities, via SAML, OpenID Connect, or OAuth 2.0. Legacy authentication is insecure and caused by the choice of client application. Legacy authentication was blocked by Microsoft in association with Exchange Online and the UW has chosen to block it entirely.