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
Related
I got a website to handle all security issues raised by a software during Pen Testing. Please refer to the following screen shot:
jquery.signalR-2.4.1 is being used in the project (ASP.NET MVC). I need to give explanation to the security team about the use of above URL, why it is showing under a GET request. Is there any threat for the application? If yes how to remove the connection string from the query string inside the URL? If it's an inbuilt process or method what's the exact use?
It's a connection token, not a session/security token. This is documented in Microsoft's SignalR security section of the documents. I would refer your security team to this information as they are not aware of the difference here and how it is used. Especially the bolded portion below:
Here it is in case the link changes -
SignalR's connection token isn't an authentication token. It is used to confirm that the user making this request is the same one that created the connection. The connection token is necessary because ASP.NET SignalR allows connections to move between servers. The token associates the connection with a particular user but doesn't assert the identity of the user making the request. For a SignalR request to be properly authenticated, it must have some other token that asserts the identity of the user, such as a cookie or bearer token. However, the connection token itself makes no claim that the request was made by that user, only that the connection ID contained within the token is associated with that user.
Since the connection token provides no authentication claim of its own, it isn't considered a "session" or "authentication" token. Taking a given user's connection token and replaying it in a request authenticated as a different user (or an unauthenticated request) will fail, because the user identity of the request and the identity stored in the token won't match.
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.
I'm using ASP.NET MVC 5 w/ .NET 4.6, and Identity 2.1. I'm migrating my app to SPA (Single Page App). I've been investigating the matter, because I got worried about CSRF/XSRF attacks. I have a couple of concerns..
I have started to implement a token-bearer approach using OAuth and JWT through Katana, by following this tutorial: http://bitoftech.net/2015/02/16/implement-oauth-json-web-tokens-authentication-in-asp-net-web-api-and-identity-2/
After implementing it, I realized that I needed to store the JWT in a safe manner. According to the Stack Exchange network and some other websites, the best way to do this is to store it in a Cookie with HTTP flags on. This would prevent the attacker from using a XSS mechanism and steal the token. Unfortunately this approach is susceptible of CSRF attacks, bringing me almost to square 1.
A mechanism suggested by the same sources is to use a Double Cookie implementation. In which I would send both: the CSRF token (random string) and the JWT. Despite that, I'm really worried about generating the CSRF token (which was my main problem). The best way (in my understanding) to retrieve an anti-forgery token is to server-render it
Therefore I get the token through #Html.AntiForgeryToken in my initial load and utilize it for subsequent requests. This creates the following concern: For how long will that token be valid? Or, how would I handle the CSRF token expiration? (Which was my main concern in the beginning)
I don't know how viable would it be to request another CSRF token from the server after the data has been sent. I'm very skeptical on retrieving tokens via AJAX calls...
I haven't found any post so far that dwells this far. So that's why I'm asking.
Edit
Giving some thought, I think I could do the following:
Instead of using the JWT as an authentication mechanism. I could use it as an anti-forgery mechanism.
I would use Identity as authentication, and the token would be passed to each request for validation.
If the user is valid and the token is valid, then go ahead.
If the user is valid, and the token invalid, invalidate the request.
If the user is valid, and the token is valid but expired, log out the user.
If the user is invalid, and the token valid, invalidate the token and the request.
I am trying to implement bearer token based validation with using Authorize attribute on a controller in MVC6.
I am following this post:
Token Based Authentication in ASP.NET Core
One guy put whatis written in the post above to:
https://github.com/mrsheepuk/ASPNETSelfCreatedTokenAuthExample
Based on this example. if client sends request to server to specific controller that is decorated with Authorize attribute, Authorize attribute will check request header called authorization and if this header will have valid token then the request will pass, otherwise request will be denied (correct me here if im wrong)
What I want to do here is I want to send the token not in authorization header, but in a cookie and take that token from cookie and validate it while still using authorization attribute on a controller.
How should I do this, I was looking at a new asp.net 5 feature authorization policies, but seems that they do not have what I need. Is there a way to do this?
You would have to write your own authentication middleware for this, which isn't exactly a fun exercise.
You'd also have to consider how to get the token into a cookie, and how to secure that cookie properly. Having a raw token in a cookie that is available to client side code, and which isn't, at the very least signed, is a security vulnerability waiting to happen.
Let me quote HTTP 1.1 RFC specification from www.w3.org.
10.4.2 401 Unauthorized
The request requires user authentication. The response MUST include a
WWW-Authenticate header field (section 14.47) containing a challenge
applicable to the requested resource. The client MAY repeat the
request with a suitable Authorization header field (section 14.8).
14.8 Authorization
A user agent that wishes to authenticate itself with a server usually, but not necessarily, after receiving a 401
response does so by including an Authorization request-header field
with the request. The Authorization field value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Why the credentials intended to prove user identity (Authentication) passed in Authorization header?
You can see it like this. The server says to the client "Please authenticate before accessing this resource" and sends information on how the client should do the authentication (WWW-Authenticate). The client is responsible for authenticating and then sends proof of that authentication to the server (Authorization).
The Basic authentication scheme messes things up because the authorization is a username and password, that is, you authorize by authenticating against the server itself (showing you know a user and password).
Nevertheless other schemes allow the client to authenticate with a third-party and only send a proof of the authentication to the server. The server can verify the authorization and may not know who the client is (although it typically does).
Note This is only a rationalization. I don't mean to say this was the motive behind the chosen names.
One possibility is that it is talking about the authorization from the user's perspective, not the server's.
There are actually two authorizations going on:
The user authorizing the client to act on their behalf.
The server authorizing the user to access its resources.
If we assume the header is named after 1) then we have:
The user authorized the client to act on their behalf. That authorization goes in the Authorization header. The server then used the user's authorization of the client to authenticate the user (confirm the client is acting on behalf of the user). Now it knows who the user is, it will then do its own separate checks for 2), to see if the user is authorized to perform the request.