I've created a Private App (got the API Key, Password, and Secret) but it's not allowing me access for some reason. I'm issuing the GET request without any parameters... should I be using something in the request? Thanks! Josh
{"response":
"Error message:
GET
https://58b135637023de04edb493880e25XXXX:2d6982192cdc0ea753ba6a729c9dXXXX#ellabing-com.myshopify.com/admin/products.json? returned a response status of 401 Unauthorized
"Server response": {
"errors":"[API] Invalid API key or access token (unrecognized login or wrong password)"
},
"remoteServiceStatus":1,
"success":false
}
Hmm… can you check the request that’s coming from your machine using a web debugging proxy like Charles or Fiddler and see if an Authorization header is really being passed in the request?
The format that https://58b135637023de04edb493880e25XXXX:2d6982192cdc0ea753ba6a729c9dXXXX#ellabing-com.myshopify.com/admin/products.json is in works for browsers and some clients, but is an unofficial shorthand, and not always supported.
Related
All,
I am facing authentication issues that I see others have also complained about. Following official documentation I was able to get the client id and client secret but when I try to get Access Token I am getting this error:
{
"error": "invalid_request",
"error_description": "A required parameter \"client_id\" is missing"
}
I am using POSTMAN to get the access token. After getting the Access Token I intend to work with LinkedIn REST APIs with other software that could consume REST. I am not sure why I am getting this error, I wonder is it not possible to get the token from POSTMAN and have to use Python script?
Also, redirect_uri in step 2 is not a functional callback uri, it's an imaginary URL. Do I need a valid callback URL?
Since you are getting this error
{
"error": "invalid_request",
"error_description": "A required parameter \"client_id\" is missing"
}
This is giving a hint that you might need to change the Client Authentication drop-down value to Send client credential in body instead of Send as Basic auth header
This is because when client_id and client_secret are sent in the header, they are combined and converted to base64
Authorization: Basic base64($client_id + ':' $client_secret)
So, no separate client_id is ever sent. But if you choose to send the credentials in body then they are sent separately.
For more info, you can refer the offical RFC here https://www.rfc-editor.org/rfc/rfc6749#section-2.3.1
I solved this issue by adding keys/values in the Params.
I am following this document to secure the rest services. I am able to obtain the access token. However when I try to use the token to invoke a service, I am getting the error -
Status: 401
WWW-Authenticate Bearer realm="bkofc", error="invalid_token",
error_description="Didn't find publicKey for specified kid"
What am I missing here ? Anything to do with the realm settings ?
401 could actually only mean, that the token is not provided correctly. The Header "Authorization" needs to be set properly. It actually works fine, when you are doint it right.
Desides, the document you are using is written by a person, who knows exactly, what to do for people, who know exaclty what to do. So may be you are just doing something wrong, which is not recognisable from your question.
I am developing RESTful APIs, I have implemented token-based authentication, where token digest is prepared using time-stamp. Now when request comes to API server, I am checking if the supplied time-stamp is invalid ( i.e. date-time from future/past is specified) then am throwing error message indicating that "future token detected" or "token has expired". I need to attach HTTP status code I am confused about which status code is suitable for this situation?
I have gone through the status codes available (ref1, ref2) so far, I think, using 400 'bad request' will be suitable here instead of 401 'Unauthorized' and 403 'forbidden' status codes.
what do you think guys?
As the timestamp is invalid, I think the token is invalid. So the client is not authenticated anymore. So I would throw a 401 Unauthorized. You're free to add extra data of the context as HTTP header with the X- prefix, or to add a response body encoded according to the Accept request header (json, text, etc.). Like:
{
"error": {
"status": 401,
"details": {
"code": "401.3",
"description": "The timestamp provided must not be in the future."
}
}
}
It is not a 403 Forbidden : 403 means "the client is authenticated but does not have the right to send this request". In your case, I think the client is not authenticated any more.
Works Around... Thinking about expired password (not exactly expired credencial)
I found this from https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
403 Forbidden
The client does not have access rights to the content; that is, it is unauthorized,
so the server is refusing to give the requested resource.
Unlike 401, the client's identity is known to the server.
//- - - -
Well I think the better is response with 403 with description or custom content header, and so the client need to call the endpoint with your auth + param with new password.
Now, about expired credencial (yet thinking about user and password, not token), 403 I think good too, because "the client's identity is known to the server" but unauthorized.
About token and your timestamp, 401 with description is good I think, because one of first steps is the server see the timestamp, and the timestamp will fail before checking any credentials..
I use OAuth 2 in a REST API and I my API returns a 401 error, if my access token is invalid.
My 401 response isn't meaningful right now and I wonder if I could place my authentication URI in my response? Something like
{
"error": 401,
"authentication_uri": "https://example.com/login?client_id=123&response_type=token&redirect_uri=http://example.com/app/"
}
Can I do that? Is this secure? (It seems that all these params are exposed in the URL anyway...) Are there other common methods to get a meaningful response from 401? I couldn't find something useful about this topic.
I am not a security expert, but I don't see a problem with doing this. I'm not aware of any value in hiding how to authenticate, and I don't see you exposing anything that they don't already have (assuming client_id and redirect_uri were in the original request).
To answer my own question: While it is certainly possible to do this and has benefits as you don't need to know the authentication URI beforehand, it has some pitfalls.
Say you develop multiple apps separately at http://localhost and you want to communicate the same REST API. The REST API can't deduce your client_id just from your Referer or Origin header field as it is always http://localhost. You could develop "App 1" or "App 2" and each has a different client_id. Therefor you would need to support URI templates. E.g.:
{
"error": 401,
"authentication_uri": "https://example.com/login?redirect_uri=http://localhost&response_type=token{&client_id}"
}
See here for more examples about URI templates.
I am currently working on a blackberry app that needs to connect to facebook chat. I am attempting to use the XMPP/Jabber interface. I can get the challenge from the server, however when I send my response I get a "not authorized" failure. My response is structured in this way:
api_key=[my api key]&call_id=[time in millis]&method=auth.xmpp_login&nonce=[nonce from challenge]&session_key=[explained below]&v=1.0&sig=[calculated as shown below]
For the session key, I send the user a browserfield to Facebook's site. It returns an access token in the form AAA...|BBB...|CCC... where BBB... is the session key
The sig is calculated by taking the following string, md5ing it, and then converting the bytes to a hexadecimal string:
api_key=[my api key]call_id=[time in millis]method=auth.xmpp_loginnonce=[nonce from challenge]session_key=[explained above]v=1.0[secret key appended here]
from there I base64 encode the response, and send:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>[Base64EncodedResponse]</response>
Facebook's response is consistently a not-authorized error, with no adidtional explanation. Is there something that is missing or something? Thanks for the help.
I was able to figure it out. The problem was, it wants the session secret, not the app secret. So the secret key appended at the end of the signature is obtained from calling auth.promoteSession, not from the App Secret on the website.