The response of Authentication grand code for the request which i pass is 200 Ok. But am getting an html response in that. i couldn't find any code. Can You please help me.?
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXfeeb89&redirect_uri=https://localhost:44330/callback
This is the request which i send. But not receiving the authentication code. But It shows 200 OK.
In the admin tool, check that your integration key is set to use Authorization Code grant, not Implicit grant.
Also check that you've authorized your exact callback URI for your integration key.
If you're not getting any errors from DocuSign, then authenticate yourself and the your browser will then be redirected to your redirect uri, in this case https://localhost:44330/callback
Related
I have some code that looks at "Basic Authorization" requests from many different sites.
I want to know if I can make the following assumptions:
A successful response (credentials are correct) will always have response code 200 OK
A failed response (incorrect credentials) will always have response code 401 Unauthorized
Are the above fair assumptions, or is the success/fail conditions configurable per site?
No, there are other possible response codes.
According to the official spec, there can also be the error code 407.
Also, on MDN:
If a (proxy) server receives invalid credentials, it should respond with a 401 Unauthorized or with a 407 Proxy Authentication Required, and the user may send a new request or replace the Authorization header field.
If a (proxy) server receives valid credentials that are inadequate to access a given resource, the server should respond with the 403 Forbidden status code. Unlike 401 Unauthorized or 407 Proxy Authentication Required, authentication is impossible for this user and browsers will not propose a new attempt.
In all cases, the server may prefer returning a 404 Not Found status code, to hide the existence of the page to a user without adequate privileges or not correctly authenticated.
Besides that, I'm quite sure that an actual successful attempt will result in status code 200.
Friends, in the Authorization code flow, it states that after the /authorize call is initiated and success, the authorization code will be sent via HTTP 302 "redirect" URL to the client(say ReactJS webapp). Why the OAuth specification requires this to be sent in a redirect so the authorization code is sent in URL parameters exposed. I know it is recommended to use PKCE to handle this auth code leak issue, but my question is why OAuth spec requires us to send the auth code in 302 redirect in URL params in the 1st place. Why cannot the client(ReactJS webapp) place a simple GET request to the IDP and why cannot the IDP send back the auth code in the response body to the react JS application(say by xmlhttprequest). Any help is appreciated. Thanks.
If you use a OAuth2 service like Google, or some other service, and your react application would be able to handle the entire flow it means it can completely act on behalf of the user.
By requiring a redirect, it means that the user's own browser will go to the auth service's website, which is the only place the user can trust to safely enter their password and grant access to your application.
The URL in the addressbar means trust. Users are trained to never enter their password in a website they don't recognize.
I have created an app (backend and frontend) that is mainly used on a Windows intranet. I'm using Kerberos authentication to do SSO so that anyone logged in to Windows domain is automatically authenticated to the server. To do this I set up Kerberos SPN for server and configured browsers etc and is all working fine in the normal scenario. My problem is that I need to continue if the user is not authenticated (ie connects from outside the Windows domain or does not have their browser configured correctly).
In summary there are two scenarios:
if authenticated OK continue with authorization granted for their ID [currently works]
if not authenticated continue with no (public) authorization [does not work]
In the first case the HTTP requests/responses are:
a. frontend: initial HTTP request
b. backend: no auth found so return 401 unauthorized with WWW-Authenticate:Negotiate header
c. frontend: re-sends request with Authorization header -> decoded to get the login ID
In the 2nd case:
a. frontend: initial HTTP request
b. backend: no auth found so return 401 with WWW-Authenticate:Negotiate (and error text in the body)
c. frontend: browser stops (displaying the body of the response as text to the user)
This is the crux of the problem I need to somehow avoid the browser just completely bombing (as at step c above).
Solutions I have tried:
display a message to the user about how to adjust browser settings to allow SSO to work in the body of the 401 response message. This is pretty ugly looking and does not work for connections from outisde the domain
Tried a 301 redirect in stead of 401 unauthorized response, but the browser does not like this.
Tried a redirect using javascript in the 401 response body, but it is not executed.
Have the backend send 401 but with WWW-Authenticate:Negotiate,Basic. But this display an unneeded login/password dialog and still fails if they don't login.
What I really need is an None option, ie: WWW-Authenticate:Negotiate,None then continue with no auth if the subsequent frontend request indicate "None" was used.
Of course, there isn't a "None" option. :(
It seems that this should be a fairly typical scenario but I have been researching this to no avail for 3 days now. Any advice would be greatly appreciated.
If the browser is connecting from outside the intranet then just continue. That is do not send the 401 response at all (no auth). You should be able to tell from the IP address where they connect from.
Another option is to redirect using JS in a page in the 401 body. As mentioned above I think you need to include Content-type: text/html or Content-type: text/javascript.
I have a problem with JMeter. When I try to send some request, it returns me a 403 Forbidden status code. I know that it needs an authentication, I've seen many things about that.
I'm working with Apache ActiveMQ Artemis. I need to execute some API request, which removes all messages in the queue. The API looks like that:
http://10.2.5.23:8161/console/jolokia/exec/org.apache.activemq.artemis:broker=%220.0.0.0%22,component=addresses,address=%22TEST.GSH%22,subcomponent=queues,routing-type=%22anycast%22,queue=%22TEST.GSH%22/removeAllMessages()
When I try to execute it, it returns me a 403 Forbidden status code. I've tried to add HTTP Authorization Manager, added this url and typed username and password, but still it gives me the same output.
This is from where I login, also I added this in HTTP Authorization Manager and set the username and password.
http://10.2.5.23:8161/console/login
Any idea or advice will help me.
I know that here are questions like mine, but I have not found what would help me.
The answer was quite simple. I've just added in HTTP Header Manager an authorization with Basic encoded. Now it works fine. But I have one question, why did HTTP Authorization Manager not work ? Why should i add authorization in header ? I can't make it only with HTTP Authorization Manager ?
I'm writing a REST-ish API service the provides the ability to interact with the end user's data in other 3rd party services (themselves REST APIs) via OAuth. A common example might be publishing data from my service to a third-party service such as Facebook or Twitter.
Suppose, for example, I perform an OAuth dance with the end user and Facebook, resulting in some short-term access token that my service can use to interact with the user's Facebook account. If that access token expires and the user attempts to use my service to publish to Facebook, what sort of error do I return to the user?
401 doesn't seem quite right to me; it seems that 401 would apply to the user's auth state with MY service. 403 seems much more appropriate, but also quite generic.
401 is the way to go. Two excerpts from the RFC2616 which defines the HTTP protocol:
Section 10.4.2 (about 401):
If the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials.
This seems to be appropriate for expired tokens. There are authentication credentials, but they're refused, so the user agent must re-authenticate.
Section 10.4.4 (about 403):
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
This should be used when the resource can't be accessed despite the user credentials. Could be a website/API that works only on US being hit by a asian IP or a webpage that has been declared harmful and was deactivated (so the content WAS found, but the server is denying serving it).
On OAuth2, the recommended workflow depends on how the token is being passed. If passed by the Authorization header, the server may return a 401. When passed via query string parameter, the most appropriate response is a 400 Bad Request (unfortunately, the most generic one HTTP has). This is defined by section 5.2 of the OAuth2 spec https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26
There's nothing wrong with being generic, and it sounds like a 403 status would be relevant - there is nothing stopping you from providing a more human readable version that elaborates in a bit more detail why.
I think the following is a comprehensive list if you have some level of ambition when it comes to error responses.
400 Bad Request
For requests that are malformed, for example if a parameter requires an int between 0-9 and 11 has been sent. You can return this, and in the response body specify parameter x requires a value between 0 and 9
401 Unauthorized
Used only for authorization issues. The signature may be wrong, the nonce may have been used before, the timestamp that was sent is not within an acceptable time window, again, use the response body to specify more exactly why you respond with this. For the sake of clarify use this only for OAuth related errors.
403 Forbidden
Expressly to signify that an operation that is well formed, and authorized, is not possible at all (either right now, or ever). Take for example if a resource has been locked for editing by another user: use the response body to say something along the lines of Another person is editing this right now, you'll have to wait mmkay?.
403 Forbidden can also have to do with trying to reach resources. Say for example that a user has access to a resource /resource/101212/properties.json but not to /resource/999/properties.json, then you can simply state: Forbidden due to access rights in the response body.
404 Not Found
The requested resource does not exist. Or the URL simply does not successfully map to an API in your service. Specify in response body.
405 Method Not Allowed
This is to represent that the API can not be called with for example GET but another method must be used. When this is returned also you MUST return the extra response header Allow: POST, PUT, etc.