Azure AD Authentication

Last updated: January 30, 2023
Audience: All UW

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’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.

The Azure AD 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 Azure AD, 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. , 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:

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. There is no automated or manual removal of external users from the Azure AD tenant. The person in control of an external user account can deprovision the account in other Azure AD tenants by themselves. 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 Azure AD sign ins are logged and you can review them. There are two locations you can go.

  • My Sign-Ins – simplified list of your UW Azure AD 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 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

Azure AD 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 Azure AD here:

You can review which applications have some consent to act on your behalf at 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. At some point in the future, we expect legacy authentication to be blocked by Microsoft.

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.

To block legacy authentication, anyone with a personal UW NetID can join (and unjoin) this group: 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 not permit legacy authentication.

If you have another type of UW NetID you’d like to opt-in, you’ll need to request it via UW-IT. Send requests to with a subject line of: “Microsoft Infrastructure: conditional access block legacy for X” where X is your unit name. Be prepared with a group of the users to block legacy authentication.