When using the Rossum API for data capture with Postman, I'm getting this error for any HTTP request after a login:
{
"detail": "CSRF Failed: Referer checking failed - no Referer.",
"code": "permission_denied"
}
It turns out that the Rossum API is Django-based and uses special cookies to prevent CSRF attacks, issued during the /login call. The CSRF cookie guard prevents from third-party websites wrongly issuing calls through a logged-in user browser - the cookie must be set in combination with a correct referer setting to verify that the call is not issued by a third-party website.
However, Postman is using the cookie but not setting a referer properly. Clearing the cookies in Postman resolves the issue.
This is also why the issue does not appear while using curl or HTML5 fetch.
Related
I have setup an authenticated endpoint that requires Slack signin via Oauth2. I have a web front-end that works great -- I can authenticate via Slack and get a token from my callback method (via JSON in the response).
If I try to implement the same flow in Paw, I see an error, "Invalid State in authorization response". From my server logs, I can see that the callback url is being hit and that the JSON is being returned, but Paw errors out and I can't inspect the response.
I'm trying to capture the JWT via "Response Parsed Body -> JSON"
Here is the paw print:
https://paw.pt/ewvrJX0L
NOTE: Authorization Grant flow doesn't work either.
It's likely that the server is not returning a state parameter as expected by the OAuth 2 spec. Some servers do not and most client libraries are deliberately accepting the response nevertheless.
Paw can ignore the state parameter and accept the server response if you uncheck the box "Strict Mode: Perform additional checks on the response".
This should help solve the problem in your case.
I am using JWT Bearer authentication scheme in a REST api. For returning jwt token to client after successful authentication, currently i am using access token response in body as described in https://www.rfc-editor.org/rfc/rfc6750#page-10
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
But need to return token in other HTTP request too like signup where body is already present.
So, was thinking of using "Authentication-Info" header for it. But Bearer Scheme does not specify "Authentication-Info" header anywhere. Should i use Authentication-Info header for returning jwt token?
Not using OAuth 2.0, just JWT.
What you have there might be correct for OAuth 2.0, but for ordinary JWT it's much simpler. When you use ordinary self-made JWT, the client will put the token on an HTTP header called Authorization. The value of the header is something like this
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
The header field could be called something else too. The server and client has to agree on the name. Authorization is just the most common name.
The server will usually issue the token by responding to the POST request on the login endpoint. The token can be a part of the response body when the login is successful. The client will store the token and send the token with every request by using the header above. You can forget everything that has to do with access token and refresh token. When using "ordinary" basic JWT you will only have one token, and that is the value after Bearer.
I don't see any reason to issue a token when the user is signing up. They can get it when they log in after signing up.
I would recommend you to read this over the RFCs for OAuth if you're just implementing ordinary authentication.
If someone tries to visit an internal page which is only accessible once they have logged in, what error code should be returned? 403 doesn't seem right, because they have not authenticated. However, 401 doesn't work either, because that implies they can log in using basic auth, which we are not using.
Is it correct, when authentication is done via a method other than WWW-Authenticate headers, to use 403 in place of 401? If not, what code should be used?
Note: I have found some similar questions to this, but they all seem to be asking about sites using http basic auth, rather than any other authentication method.
The status code 401 does not imply you support basic authentication. It means that the server would not serve the request because appropriate credentials were missing.
The server can send back a WWW-Authenticate header to indicate what types of credentials it supports. If you only support JWT tokens for example, you would send back 'bearer'.
I'm sending username and password in the HTTP Body for authentication to each controller action in a Web API. I do the authentication in each controller using the username/password. It's using SSL.
Are there any security reasons why it's better to send the authentication credentials in the HTTP Header than in the HTTP body?
If I was using Basic Authentication I can see how having the credentials in the header are necessary as in this question but I'm not so I don't see the purpose. It seems just as secure in either as long as it's using SSL.
From an SSL perspective the security of the credentials in header (HTTP Basic auth) or body (e.g. form based logon) of an HTTP request is equal.
However if the client is a regular web browser you should consider the following:
Browsers cache the credentials used with HTTP basic authentication the users usually face the problem that for performing a log-out they would have to close their browser.
On the other side a form-based logon usually created a session cookie that is time restricted and can be deleted any time.
Which status code would you use in this scenario, assuming you're using a token based authentication:
The client has a token and makes a request to the server.
The token expired and the server sends a 401 Unauthorized.
The client sends the refresh token.
The token is invalid and the server responds with XXX?
The use case would be an application, that automatically catches 401's and makes a request with the refresh token. If the server would respond with a 401 if this token is not valid, the client would try to request a new access token with the refresh token forever. But it should tell the client, that it should re-authenticate with its credentials (e.g. email and password).
I was just wondering which status code would be the best fit in this scenario, as the spec says in case of a 403 Forbidden "authorization will not help".
I would not make access and refresh tokens interchangeable: Use Access-Tokens to access protected resources and use Refresh-Token to fetch new Access-Token from a special end-point. OpenID Connect works this way.
You would have one HTTP request more but HTTP codes would not be a problem and, in my opinion, you would get a cleaner code.