Currently when a Power BI API call is made with an expired access token, a 403 Forbidden response is returned, with the following response body:
{ "error": { "code": "TokenExpired", "message": "Access token has expired, resubmit with a new access token" } }
Standards and best practices
The RFCs generally are quite vague about the difference between 401 and 403 error responses and where they are to be used. The fact that the words "authentication" and "authorization" seem to be used interchangeably doesn't help matters.
The public consensus based on StackOverflow posts and blogs does seem to be that 401 is the appropriate response when the client includes an otherwise valid but expired access token in the Authorization header of the request.
This is underlined by:
- the fact that browsers will prompt for authentication (via a modal dialog) when a server returns a 401 response with a WWW-Authenticate header, but not when a server returns a 403 response;
- the fact that RFC 2616 and RFC 7235 indicate that 401 means the credentials (i.e. access token) presented are not acceptable for authorization - an expired token would fall under this category;
- The fact that RFC 6750 explicitly states that for OAuth2-protected resources, 401 must be returned as the response codes for requests to a resource that use an expired access token.
I've quoted some relevant RFCs and posts/articles below for convenience.
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8). If
the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials. If the 401 response contains the same challenge as the
prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity might
include relevant diagnostic information. HTTP access authentication
is explained in "HTTP Authentication: Basic and Digest Access
Authentication" [43].
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. If the server does not wish to
make this information available to the client, the status code 404
(Not Found) can be used instead.
RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
6.5.3. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that
reason in the response payload (if any).
If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons
unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of
404 (Not Found).
RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
3.1. 401 Unauthorized
The 401 (Unauthorized) status code indicates that the request has not
been applied because it lacks valid authentication credentials for
the target resource. The server generating a 401 response MUST send
a WWW-Authenticate header field (Section 4.1) containing at least one
challenge applicable to the target resource.
If the request included authentication credentials, then the 401
response indicates that authorization has been refused for those
credentials. The user agent MAY repeat the request with a new or
replaced Authorization header field (Section 4.2). If the 401
response contains the same challenge as the prior response, and the
user agent has already attempted authentication at least once, then
the user agent SHOULD present the enclosed representation to the
user, since it usually contains relevant diagnostic information.
RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
3.1. Error Codes
When a request fails, the resource server responds using the
appropriate HTTP status code (typically, 400, 401, 403, or 405) and
includes one of the following error codes in the response:
invalid_request
The request is missing a required parameter, includes an
unsupported parameter or parameter value, repeats the same
parameter, uses more than one method for including an access
token, or is otherwise malformed. The resource server SHOULD
respond with the HTTP 400 (Bad Request) status code.
invalid_token
The access token provided is expired, revoked, malformed, or
invalid for other reasons. The resource SHOULD respond with
the HTTP 401 (Unauthorized) status code. The client MAY
request a new access token and retry the protected resource
request.
insufficient_scope
The request requires higher privileges than provided by the
access token. The resource server SHOULD respond with the HTTP
403 (Forbidden) status code and MAY include the "scope"
attribute with the scope necessary to access the protected
resource.
Question:
For a web page that exists, but for which a user does not have sufficient privileges (they are not logged in or do not belong to the proper user group), what is the proper HTTP response to serve?
401 Unauthorized?
403 Forbidden?
Something else?
What I've read on each so far isn't very clear on the difference between the two. What use cases are appropriate for each response?
Highest ranked answer:
A clear explanation from Daniel Irvine [original link]:
There's a problem with 401 Unauthorized, the HTTP status code for authentication errors. And that’s just it: it’s for authentication, not authorization. Receiving a 401 response is the server telling you, “you aren’t authenticated–either not authenticated at all or authenticated incorrectly–but please reauthenticate and try again.” To help you out, it will always include a WWW-Authenticate header that describes how to authenticate.
This is a response generally returned by your web server, not your web application.
It’s also something very temporary; the server is asking you to try again.
So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401.
Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”
In summary, a 401 Unauthorized response should be used for missing or bad authentication, and a 403 Forbidden response should be used afterwards, when the user is authenticated but isn’t authorized to perform the requested operation on the given resource.
Another nice pictorial format of how http status codes should be used.
Receiving a 403 response is the server telling you, “I’m sorry. I know who you are--I believe who you say you are--but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”
In summary, a 401 Unauthorized response should be used for missing or bad authentication, and a 403 Forbidden response should be used afterwards, when the user is authenticated but isn’t authorized to perform the requested operation on the given resource.
frithjof_v
on:
Delete multiple queries in Fabric SQL Database
miguel
on:
Fabric Engineering - Dataflow Gen2 - Enhancement -...
on:
Enforce Role Inheritance from Snowflake in Power B...
on:
Show and Hide Visual Elements Using DAX or Conditi...
timcalil
on:
Tableau has an inbuilt functionality of ‘underlyin...
on:
Add Option to Control Visibility of Visuals and Bu...