Can I send a bearer token in both a header and a query parameter?

An OAuth bearer token must be sent using only one transmission method in each request. Including it in both the Authorization header and a query parameter can cause an invalid_request error, for which the standard recommends 400.

Is a lowercase authorization header name invalid?

No. HTTP header names are case-insensitive, so authorization and Authorization name the same field. That rule does not let you change the characters in a password or token value.

Does Base64 encoding encrypt a Basic authentication password?

No. Base64 is an encoding, not encryption. Basic credentials need a protected transport such as HTTPS to avoid exposing them on the network.

What is 407 Proxy Authentication Required?

407 indicates that a proxy requires authentication to use it for the request. It uses a proxy-specific challenge rather than the origin resource's 401 challenge.

Can a 401 response include an HTML login page?

Yes. A server can return HTML content with a 401 status, including a login page or an explanation of the authentication failure.

Why would a browser's CORS preflight request receive 401?

A CORS preflight normally carries no credentials, so requiring authentication for that OPTIONS request can cause a 401 and prevent the actual request from being sent. The owner should configure the permitted preflight response while keeping authentication on the protected resource request.

What does a realm in a Basic challenge identify?

A Basic realm labels a protected area, and its credential scope also depends on the server's scheme, hostname, and port. The same realm name on a different origin does not authorize sending that server your password.

Can a server clock affect a time-limited token?

Yes. For tokens with expiration or not-before timestamps, the server checks those values against its current time. The owner should correct a badly skewed server clock rather than disable time checks.

Can a redirect cause an authenticated request to return 401?

A browser removes the Authorization header when following a redirect to a different origin. The destination may return 401 if it needs that header, so check the redirect chain and use the service's documented endpoint.

Can a client send credentials before receiving a 401?

Yes, a client may send credentials preemptively when it already knows the applicable scheme and protection space. It should follow the service's documented flow and avoid sending secrets to an unintended endpoint.

How to Fix a 401 Unauthorized Error

A 401 Unauthorized response means a request lacks valid authentication credentials for the target resource. The word “Unauthorized” in the status name can be misleading: first check how the server expects the client to authenticate, then renew or supply legitimate credentials.

If the account is already authenticated but lacks permission for the requested resource, a 403 response is a different situation. For a visitor, normal sign-in or account recovery may resolve a 401. For an API owner, the response headers and the credentials actually sent help identify why authentication failed.

Find the Authentication Challenge

Identify the request that returned 401, including its host, path, method, and time. A page may make background API calls, so the error shown in a browser can belong to a request other than the main document. Inspect the response headers using your browser's network tools or an API client. The required WWW-Authenticate response header identifies one or more applicable authentication schemes and may provide details needed to respond.

If the field is missing from a response labeled 401, the implementation or intermediary may be inconsistent with HTTP requirements; the owner should inspect the component that generated it. Do not guess a scheme from the appearance of the login page. A reverse proxy can also issue an authentication challenge before the application handles the request.

Match the Required Authentication Method

Check the service's instructions for the credentials its endpoint accepts and where to send them. If it requires an Authorization header, placing an API key in the query is not a substitute.

Confirm that the Authorization header reaches the endpoint and uses an accepted scheme. If the API uses a token, check that it was issued for this environment and for the intended API, often identified as its audience. A staging credential sent to production may be valid in one place and useless in another.

If the endpoint expects a bearer token in the Authorization header, the value contains Bearer followed by a space and the access token. Check for extra quotation marks or line breaks introduced when copying the value. Use the access token issued for that API; a refresh token or an ID token intended for signing in to an application serves a different purpose.

For a website, use the site's ordinary sign-in flow and verify that the account is active. A session can expire or be invalidated while a tab remains open. After signing in, open the intended page again and check whether the site recognizes your session. If the site asks for credentials on an unexpected hostname, do not submit them just to clear the error; verify the destination through the service's normal entry point.

Renew Credentials and Check Access Scope

When the service reports that an API token expired, obtain a fresh token through its documented authorization process. Revoking account access, changing a password, or updating an application's authentication settings can invalidate credentials before they expire.

Repeatedly trying random credentials can trigger account protections and does not diagnose the challenge. An account owner should use recovery or support when legitimate access cannot be restored.

For OAuth bearer authentication, an invalid_token error can indicate an expired, revoked, malformed, or otherwise unacceptable access token. An insufficient_scope error is different: the token does not grant the privileges that the resource requires, and the standard recommends 403 for that condition. Requesting an approved scope through the service's authorization process may be necessary; simply replacing a token with another carrying the same permissions will not add access.

Compare Browser and API Requests

If the browser succeeds while an API call fails, compare the actual target resource and the authentication method. The browser may carry a session cookie for a web page, while the API requires an Authorization header. The two clients may contact different hosts, even if their interfaces describe the same account. Matching visible usernames is not enough to establish that both requests present the same accepted credentials.

If the API succeeds but a browser view returns 401, examine the browser's session state and the specific request that failed. The site may call an API from the page with a separate credential that expired. An owner can correlate the response with application and gateway logs using a request identifier and time.

Replace Exposed Credentials

If a password or token was exposed during troubleshooting, treat that disclosure as a separate security event. Revoke or rotate the affected credential using the service's normal administration process, then update the authorized client. Deleting a screenshot does not make an exposed password or token safe to use again.

Retest without Exposing Credentials

After correcting one identified issue, make a single harmless request to the protected resource. A successful response for the intended account shows that the server accepted the credentials for that request.

When reporting the problem, include the request method, route, timestamp with time zone, response status, and relevant header names. Replace secret values with placeholders in any example you share. The owner can inspect whether a proxy, authentication service, or application issued the challenge and correct that component. Preserve the authentication policy while fixing a mismatched or expired credential.