Android应用Azure AD认证后调用受保护WebAPI遇401未授权错误

It’s frustrating when you’ve successfully grabbed a token but still get blocked from your API. Let’s break down the most likely causes and how to validate each one:

1. Verify the Token’s Target Resource (Audience) Matches Your API #

The most common culprit is a mismatch between the token’s aud (audience) claim and your Web API’s registered Application ID URI.

• Grab your access token and decode it using a tool like jwt.ms (you can do this right on your device or desktop).
• Check if the aud value exactly matches the Application ID URI you set for your Web API in Azure AD.
• In your code, double-check that RESOURCE_ID is set to the Web API’s Application ID URI, not your Android app’s client ID—this is a super easy mix-up!

2. Confirm Permissions Are Properly Configured in Azure AD #

Even if you have a token, it might not have the right permissions to access your API:

• In the Azure Portal, go to your Android app’s registration → API permissions
• Make sure you’ve added the delegated permissions for your Web API, and that they’re either:
  • Marked as Granted for [your tenant] (if you’re using a work/school account), or
  • You’ve completed admin consent (required for some permissions)
• Decode your token again and check the scp claim—it should list the permissions you’ve requested. If it’s missing, your permission setup is incomplete.

3. Check Token Validity and Issuer #

A valid token needs to be unexpired and issued by a trusted authority:

• In the decoded token, check the exp (expiration time) to ensure it hasn’t passed.
• Verify the iss (issuer) claim matches the authority your Web API trusts. For example, if your API is in tenant contoso.com, the issuer should be https://login.microsoftonline.com/contoso.com/v2.0 (or v1, depending on your setup).

4. Ensure You’re Using the Token Correctly in API Calls #

Even a valid token will fail if you don’t attach it properly to your API request:

• You must include the token in the Authorization header with the Bearer prefix. For example, using OkHttp:

  String accessToken = /* your acquired token */;
  Request request = new Request.Builder()
      .url("https://your-api.azurewebsites.net/api/endpoint")
      .addHeader("Authorization", "Bearer " + accessToken)
      .build();
  

• Double-check that there are no typos in the header name or the Bearer spelling—small mistakes here cause big headaches!

5. Validate ADAL Configuration in Your Code #

Let’s look at your azureADLogin() method for potential gaps:

• AUTHORITY: Ensure it points to the correct Azure AD tenant (e.g., https://login.microsoftonline.com/your-tenant-id). If your API is in a different tenant than your app, this will cause issues.
• REDIRECT_URI: Confirm this exactly matches the redirect URI registered for your Android app in Azure AD. ADAL won’t return a valid token if there’s a mismatch here.
• Silent Token Acquisition: When using acquireTokenSilentAsync, make sure the userId you’re passing is associated with a token cached for your target RESOURCE_ID. If the cache has a token for a different resource, you’ll get a token that doesn’t work for your API. Check ADAL logs (you’ve set up logging—great!) to see which token is being retrieved.

6. Check ADAL Logs for Clues #

You’ve already set up ADAL’s external logger, so dig into those logs:

• Look for messages about token acquisition—do they show the correct resource ID?
• Are there any warnings or errors during silent acquisition that might indicate a cached token issue?
• The logs might also reveal if there’s an issue with the authority or redirect URI that’s not obvious in code.

Start with these checks—most 401 cases with valid tokens boil down to one of these issues. Let me know if you find something off or need help decoding the token claims!

内容的提问来源于stack exchange，提问作者Mohmmad Farooq Bhat