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.
Related
I created an jwt token based application with React and Symfony. Client & Server are completely separated. Symfony - API Server. React - Client.
Now i want to use websockets so i installed goswebsocketbundle. Everything works fine but unsecure. I don't know how to send token in socket/connect function or subscribe to access topic. Is passing parameters allowed in WAMP?
Help me please.
You need to send the token in request header and receive it from response body.
For dummy request tests you can use postman.
Authorization Code Grant is one of the four authorization grant types in OAuth2. In Implicit Grant, authorization token is directly sent back in response, but in Authorization Code Grant, code is sent back in response, which will then be used for retrieving token from authorization server.
My question is, why Authorization Code is necessary for Authorization Code Grant, instead of directly sending back token as is done in Implicit Grant?
With the authorization code grant, the exchange of an authorization code for a token happens on the server-side (i.e. not directly in the browser). This way the client secret and token can be kept more "safely" on the server. Read here about the "simplifications" the implicit flow makes at the expense of some security implications
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'.
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.
The HttpUnit API for webclient says that "Will only send the authorization header when challenged for the specified realm." What does challenged mean in this case? How does HttpUnit recognize a challenge?
This refers to the way HTTP Authentication works:
When accessing a protected URL (for the first time, with no credentials included in the request), the server will send back a response that has a status code of 401 Unauthorized and a WWW-Authenticate header set to something like Basic realm="My Realm". This indicates that Basic authentication is needed for the given URL and the realm is named 'My Realm'. This is the challenge - the user agent is being informed by the server that the URL it tried to access requires authentication and it should send back the user credentials. The user agent will typically prompt the user for credentials and then retry the request, this time with a Authorization header set to something like Basic rXflcjMwYXxz where the second part is the Base64 encoded username and password pair.
In case of the HttpUnit method you've linked to, you'll see that it requires a realm, username and password. I imagine that when the a URL is accessed, if it gets back a 401 (the challenge) from the server, it'll compare the realm you passed it with the realm in the response; if it matches, it'll attempt to authenticate with the username and password supplied.
References:
RFC entry for 401
Headers for authentication
Basic access authentication
When the server responds with a 401 error, the HttpUnit throws an AuthorizationRequiredException. We can use getParameter("realm") of the exception to get the realm and send a request again with this realm name.