I've got a JSON REST API. There is a handshake that will give you a token that is valid for 15 minutes. All calls you do within those 15 minutes should work ok. After the 15 minutes I am returning an error object (includes code, message, success = false) but I was also wondering what HTTP Error Code I should return? And will using a HTTP error code mess up certain clients? (HTML5, iPhone, Android). What is considered best practice in this scenario?
You should return a 401 Unauthorized Status Code. You might additionally provide hypermedia to establish the token again
Think about what happens in a web app. You go to say a banking site. If not auth'd it will send you to the log in page. Then you log in and you are good to go for a time. Then it expires and the cycle repeats.
Just a thought.
according to the spec rfc6750 - "The OAuth 2.0 Authorization Framework: Bearer Token Usage", https://www.rfc-editor.org/rfc/rfc6750, p.8, section 3.1, resource server should return 401:
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.
FWIW Facebook uses 400 with a custom JSON response. I personally would prefer 401 with custom JSON response.
Here is FB's response body:
{
"error": {
"message": "Error validating access token: Session has expired on Jul 17, 2014 9:00am. The current time is Jul 17, 2014 9:07am.",
"type": "OAuthException",
"code": 190,
"error_subcode": 463
}
}
Related
I want to use the Speech-to-text API for an application made in nocode.
I get this error message:
There was a problem setting up your call.
Raw response for API
401 status code
{
"Mistake": {
"code": 401,
"message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie, or other valid authentication credentials. See https://developers.google.com/identity/sign- in/web/devconsole-project.",
"status": "NOT AUTHENTICATED"
Thanks in advance
I may be able to transcribe an audio file to text.
I created the code which get the member's information by Google Workspace Directory API. This code is executed everyday, and sometime I fece the error which is "oauth2: cannot fetch token: 401 Unauthorized".
Bad thing is that this error is happend only 1-2 times per month, and I cannnot reproduce by myself. I mean, if I re-execute the code after facing this error, it works well.
I paste full error message below:
"failed to get the members by email, email ="***#***": Get "https://admin.googleapis.com/admin/directory/v1/groups/***": oauth2: cannot fetch token: 401 Unauthorized
Response: {
"error": "unauthorized_client",
"error_description": "Client is unauthorized to retrieve access tokens using this method, or client not authorized for any of the scopes requested."
}"
API is executed by using Service Account which has appropriate roles below:
https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.readonly
Is it only better solution to use exponential back off?
Thank you in advance.
Is it possible to delete the message in the response?
{
"message": "PERMISSION_DENIED: The API targeted by this request is invalid for the given API key.",
"code": 403
}
I prefer not to expose information to users. In this particular case a 403 http error would be enough.
I am designing a POST Restful API, where I have a situation that I have to authorize a user based upon one of the element provided in the request body.
For eg.
{
division : "1",
name : "MyName",
address:{
no : 123,
street : "abc",
pincode : 222111
}
....
}
So the user making POST request should be authorized to work on division 1. I cannot authorize the user without getting request body.
Also to validate some of the attributes I have to make heavy DB calls in the DB , for eg, to check the above address has a valid value of pincode.
So My question is how should I return the error codes to the user -
[EDIT]If division is not valid(something that doesnt exist in system) in the request - 400 or 403 ?
If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403 ?
What should be the error code if pincode is mandatory attribute and is not provided in the request. Should I first check 403 and then 400 or reverse ?
Basically which error code to proceed the other ?
Also is it okay to do something like :
400 – request is bad, syntactically (division/pincode or other mandatory values not provided)
403 – authorize user
400 – request is bad, data specific validation (heavier operation, requiring to hit DB)
[EDIT] we preferred not to use 422 error code
When in doubt, just take a look at the RFC
400 Bad Request
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
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.
If division is not provided in the request - 400 or 403?
I don't think either apply. The syntax -although it's missing some data- is not malformed.
Also 403 seems incorrect because of reasons mentioned above in the quote: authorization will not help etc.
How about 422 Unprocessable Entity?
422 Unprocessable Entity (WebDAV; RFC 4918)
The request was well-formed but was unable to be followed due to
semantic errors.
That is what I usually use in situations like this.
If division is provided, but user is not authorized and pincode is invalid - 400 for invalid pincode or 403?
Again, I don't think either 400 or 403 make a good case here. Specifically for this situation, 401 exists
401 Unauthorized
Similar to 403 Forbidden, but specifically for use when authentication
is required and has failed or has not yet been provided. The response
must include a WWW-Authenticate header field containing a challenge
applicable to the requested resource. See Basic access authentication
and Digest access authentication.
I think you're in the right track. Assuming that every request is being authenticated via (http authorization header)
Returning 400, on missing data is OK, and furthermore you can add error response body explaining what was the reason for the Client request not being accepted (in this case the missing division).
Returning 403, is OK if the client making the request is not authorized to interact with the resource (in this case the division).
You must validate first if the Client is authorized to interact with the resource, so 403 must be sent first, and if a required field is missing you can treat it as a 400 (with a proper explanation).
In case the Client is not authenticated, the correct response should be 401, but like I said before, 1) and 2) in my response are assuming that the Clients are authenticated against the server.
Hope it helps,
Jose Luis
recently we encountered some strange behavior of server side access token. It expires in very short period (about 15 min). Scenario is following: User login to our page via facebook (server side) and we store access token. Some actions on our page can trigger post /feed. After few feed posts we suddenly started to getting error 400 and error 401.
Error 400 is probably due to limit of number of posts, but after error 401 access token becomes expired.
Every action respond with:
{
"error": {
"message": "Error validating access token: Session has expired at unix
time 1346321603. The current unix time is 1346320983.",
"type": "OAuthException",
"code": 190
"error_subcode": 463
}
Its hard to reproduce this behavior but we reproduced it couple of times on test environment (so we know when access token is created, that user didn't deauthorize app, nor change password).
Any ideas why access token becomes expired?
I double check that "Remove offline_access permission" was enabled on application advanced settings so i can get 60 days server side token.
Not sure why, but all access token have expire "in about hour" reported from access token debugger.
I created new application (also with "Remove offline_access permission") and now i got tokens which expires in 2 months.
Not sure why, but answer was to create new application.
By default facebook assigns a short lived access token. You need to request for long lived token.
Read the doc for how to get it : http://developers.facebook.com/roadmap/offline-access-removal/#extend_token
EDIT:
Previous link doesn't work anymore, use following link
https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal/