Azure-cli: az status

[jjasghar]

az status will tell you who you are logged in as if you are logged in.

I imagine the ability to get the same info after you use az login

~ > az login
Note, we have launched a browser for you to login. For old experience with device code, use "az login --use-device-code"
You have logged in. Now let us find all subscriptions you have access to...
[
  {
    "cloudName": "AzureCloud",
    "id": "1e0b427a-fake-494e-numbers-ee558463ebbf",
    "isDefault": true,
    "name": "Engineering",
    "state": "Enabled",
    "tenantId": "THIS_IS_FAKE-afe1-4696-NOPE-f97a7ac416d7",
    "user": {
      "name": "[email protected]",
      "type": "user"
    }
  },
  {
    "cloudName": "AzureCloud",
    "id": "b02e675a-FAKE-49bd-IDSARECOOL-daa7ed05bf4e",
    "isDefault": false,
    "name": "Solutions",
    "state": "Enabled",
    "tenantId": "NEVEREVER-afe1-4696-PUTTHISOUT-f97a7ac416d7",
    "user": {
      "name": "[email protected]",
      "type": "user"
    }
  }
]

For instance:

~ > az status
You are logged in and authenticated. Now let us find all subscriptions you have access to...
[
  {
    "cloudName": "AzureCloud",
    "id": "1e0b427a-fake-494e-numbers-ee558463ebbf",
    "isDefault": true,
    "name": "Engineering",
    "state": "Enabled",
    "tenantId": "THIS_IS_FAKE-afe1-4696-NOPE-f97a7ac416d7",
    "user": {
      "name": "[email protected]",
      "type": "user"
    }
  },
  {
    "cloudName": "AzureCloud",
    "id": "b02e675a-FAKE-49bd-IDSARECOOL-daa7ed05bf4e",
    "isDefault": false,
    "name": "Solutions",
    "state": "Enabled",
    "tenantId": "NEVEREVER-afe1-4696-PUTTHISOUT-f97a7ac416d7",
    "user": {
      "name": "[email protected]",
      "type": "user"
    }
  }
]

[tjprescott]

How is this different from az account list to list all subscriptions, or az account show to show the currently logged in subscription?

[jjasghar]

Oh! I totally didn't realize that they were commands to do that already.

I guess it would just basically be an alias to az account list. I was trying to figure out a quick and way to see if I was logged in without logging in and out.

If there a templatized way to make aliases for az? If so I'd like to take a stab at that PR.

[jjasghar]

You could even take the az status command to the next level too. az status could give you a readout of the https://azure.microsoft.com/en-us/status/ page too, so you could see the health of the Cloud and that you are authenticated too.

[hectoralicea]

when you logged in using a VM identity, you cannot see which identity is being used. You get an output such as:
"user": {
"assignedIdentityInfo": "MSI",
"name": "systemAssignedIdentity",
"type": "servicePrincipal"
}
which means nothing. Would like to know which Identity Object the VM is using.

[keremispirli]

@tjprescott @jjasghar az account show and az account list only show the local information which may have been expired; it does not check if you need to login or not. You can try by removing "~/.azure/accessTokens.json" and az account show and az account list will still work.

As a workaround you can use az account get-access-token --query "expiresOn" --output tsv to get the expiry date of your current token and check if it's still valid. (For some reason this command takes 3 seconds.)

az status can check this automatically and output something like

Your Azure session has expired! Please use `az login`.

[yonzhan]

add to S165.

[jiasli]

Currently Azure CLI has an equivalent command az account list --refresh. Please let us know if this suits your need.

[sean-nixon]

@jiasli I just came across this issue. I'm also interested in having a programmatic way to easily tell if I'm logged in and have a valid authentication context. My primary use case for this is scripts. The command you recommended does sort of work for interactive sessions, but not very well for scripting. Even if my session has expired, the command exits with a 0 status code and stdout still includes all of the cached subscriptions.

The only difference is stderr has some none machine-friendly error output related to the failed refresh:

Refreshing for '[email protected]' failed with an error 'Get Token request returned http error: 400 and server response: {"error":"invalid_grant","error_description":"AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '2020-03-30T20:55:02.7650926Z' and the TokensValidFrom date (before which tokens are not valid) for this user is '2020-04-01T20:17:30.0000000Z'.rnTrace ID: xxxxxx-xxxxx-xxxx-xxxx-xxxxxxxxxxrnCorrelation ID: xxxxxxxx-xxxxxx-xxxx-xxxx-xxxxxxxxxxxrnTimestamp: 2020-04-02 23:23:34Z","error_codes":[50173],"timestamp":"2020-04-02 23:23:34Z","trace_id":"xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx","correlation_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx","error_uri":"https://login.microsoftonline.com/error?code=50173"}'. The existing accounts were not modified. You can run 'az login' later to explicitly refresh them

I am in favor of an az status command (or it could even be az login --status to make its related to login information). As for output, it would be useful to have an option for JSON output of some kind. One option would be a list of authentication contexts and if they're still valid or expired (like a filtered and sanitized ~/.azure/accessTokens.json). Or maybe even exclude expired/invalidated tokens. If there's no valid, non-expired context, output could then either be an empty array or even just an error message and a non-zero exit code.

[jiasli]

With the current implementation of ADAL, we can't force ADAL to acquire an access token from refresh token using acquire_token. There is no force_refresh option to control it. If the token found from the cache is still within the expiration time, ADAL will consider it valid, even though the server may have disabled this user/service principal or his/her/its permissions.

Though there are some hack like modifying expiresOn from ~/.azure/accessTokens.json to force a refresh, this is not an elegant solution.

As we are migrating to MSAL, we will consider implementing az status --fresh or az account show --refresh so that az can check with AAD server whether the refresh token is still valid.

For now for scripting purpose, as a workaround, perhaps you can do an ARM request like az account list-locations and check the result code? This can reflect whether you still have a valid authentication context.

[sean-nixon]

@jiasli That makes sense. That's a good suggestion to use az account list-locations for scripting. Thanks!

[yonzhan]

MSAL