IT Connect
Your connection to information technology at the UW

Azure AD Authentication

Azure AD provides authentication via SAML, OpenID Connect, and OAuth 2.0. This page covers topics related to user authentication with Azure AD. For more on application integration with Azure AD, see Azure AD Applications.

Azure AD Authentication topics

UW NetID integration

UW’s Azure AD is integrated with the UW NetID system. If your UW NetID is “pottery” then your Azure AD username is 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 Azure AD 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 Azure AD.

At this time, the Azure AD domain is federated.

Federated Authentication Experience

The Azure AD domain is federated with the UW ADFS service, In turn, the UW ADFS service is federated with the UW identity provider, This means that after you provide your UPN, Azure AD will redirect you to, which will redirect you to, where you’ll see the familiar sign in experience there.

After you’ve entered the UPN, Microsoft first checks to see what type of account it is, and whether there are multiple types of accounts with that 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.

The typical sign-in experience for a federated Azure AD user account is detailed here.

Cloud-only Authentication Experience

We are synchronizing the NETID Active Directory password hashes to the Azure AD. At some point in the future, we will transition the Azure AD from federated authentication to cloud-only authentication. This event should not be disruptive–it only changes the user experience.

Individual users can be configured with this cloud-only authentication experience now. To do so, anyone with a personal UW NetID can join (and unjoin) this group: If you have another type of UW NetID you’d like to opt-in, you’ll need to request it via

After joining the group, you’ll need to wait for Azure AD Connect to synchronize the group to Azure AD which could be up to an hour. Any sign in after that should follow the cloud-based authentication experience. We recommend that you have also opted into the Duo 2FA for Web. That combined experience of cloud-only authentication with Duo 2FA is documented here.

External Users

Azure AD allows users from other organization’s Azure AD tenants and personal Microsoft Accounts to be guest users in your Azure AD tenant. These guest users are called External Users. Once an external user is present in your Azure AD tenant, they can be permitted access to resources in our Azure AD tenant. Azure AD 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 Azure AD enterprise tenant, we allow any user in the tenant to invite external users. In the future, as Microsoft develops the management capabilities for external users, there may be additional restrictions or limitations.

Your Azure AD account may be an external user in another organization’s Azure AD. You can tell whether it is or not by going to You can remove your external user account in those other organizations via that same interface.

Your sign ins

Your Azure AD sign ins are logged and you can review them. See for more info.

2FA Authentication

Token lifetimes, Remember me, and Preventing Misuse

Unlike the UW identity provider, Microsoft’s Azure AD 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 Azure AD 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 Azure AD; an Azure AD identity token essentially lives forever unless something happens to require a fresh sign-in.

An Azure AD access token (constrained to the AAD application) is obtained when the user wants to access an application which uses Azure AD for authentication. Azure AD access tokens do not live forever.  By default Azure AD 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

When misuse is detected on a Azure AD user account, all of that account’s tokens are revoked and an Azure AD Conditional Access policy blocks issuance of any new Azure AD access tokens until the account can be returned to service. For more information about token revocation, see


For token lifetime, there is also an administrative control called authentication session management, by which Azure AD 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 Azure AD tokens, see

Conditional Access

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

“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. At some point in the future, we expect legacy authentication to be blocked. For example, Microsoft plans to turn most legacy authentication off for Exchange Online in 2021.

Departmental IT units should read more about legacy authentication, leverage the reporting resources we’ve provided, and when ready, block legacy authentication for their users.

Last reviewed September 3, 2020