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.
Related
I'm developing a web application using symfony and JWT token for authentication. For preventing XSS, JWT token is stored in cookies with HttpOnly attribute. And for preventing CSRF, I used random csrf token. This token are stored in cookie and JWT token (encrypted). What I want to know is, is it necessary to renew csrf token in every response? Whats the best implementation?
Here's my settings in details:
We've got a single page app. Most requests will be sent using ajax.
The user authenticates using POST.
On successful authentication, the server will generate random csrf token then store it in the cookies (HttpOnly) and inside JWT payload. Before it is stored in JWT payload, the csrf token will be encrypted.
After JWT token is encoded, it will be stored in cookies (HttpOnly)
Evertime user request to access another page, the server will validate the csrf token in cookies dan JWT token when JWT token decoded.
LocalStorage is not used because it is accessible through javascript
Generally there is no need to renew CSRF token at every request.
BUT let's see what happens in your setting:
you store your JWT as well as CSRF token in cookie,
you visit malicious website that provoques a malicious request with malicious data to your site,
your browser attaches a cookie to this request with JWT+CSRF,
your security is broken.
So you must not put CSRF token in cookie because it is useless whether you renew it or not.
If you use "single page application" it would be better to pass JWT in Authorization header. That makes CSRF-attack impossible (watch out anohter threats).
If you use "classical web application" it would be better to use "classical" CSRF tokens and "classical" session identifiers.
In my project I use the identity server 4, an SPA (Angular) and a protected API (PHP). I decided me to use the reference token. My Client (SPA) works with implicit flow (is it correct not to use a client secret?) And gets the access token after login (call the authorize endpoint). After that the SPA have to send the token to the API so the API can ask the identity server 4 (introspection endpoint), if the access token is correct and the API can get access to the user´s information.
Now I want to know, how to secure the communication. Because the access token has no information in it, is it necessary to send him with jwt to the API or is it enough with a normal JSON send? As I understand the API must call the introspection endpoint with jwt bearer.
Is this method secure or what else should I do?
There is no such requirement - the API to call the introspection with a JWT. If the API is set to work with JWT's it will just verify the signature of the token with the public key from IDS. If it is set to work with reference token - it will call the introspection, to get the user info (which is the payload of the JWT). Reference tokens documentation.
Your API needs to be protected with its ID and Secret, so that you can call the introspection endpoint.
When calling it you send the reference token (it is still an access token, but it is not a JWT), the client_id and the client_secret. The content-type of the request should be application/x-www-form-urlencoded and it should be POST.
The response from the introspection endpoint is the user info.
No need of additional security - the client ID and Secret are the security, and the call is made server-to-server from API to IDS (assuming you are behind https of course)
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
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.
I have created JWT based Authentication in my Web API application.
I am not able to figure out the difference between
Basic Token
Bearer Token
Can someone please help me?
The Basic and Digest authentication schemes are dedicated to the authentication using a username and a secret (see RFC7616 and RFC7617).
The Bearer authentication scheme is dedicated to the authentication using a token and is described by the RFC6750. Even if this scheme comes from an OAuth2 specification, you can still use it in any other context where tokens are exchange between a client and a server.
Concerning the JWT authentication and as it is a token, the best choice is the Bearer authentication scheme.
Nevertheless, nothing prevent you from using a custom scheme that could fit on your requirements.
Basic authentication transmits credentials as user ID/password pairs, encoded using base64. The client sends HTTP requests with the Authorization header that contains the word Basic word followed by a space and a base64-encoded string username:password.
Authorization: Basic ZGVtbzpwQDU1dzByZA==
Note: For basic authentication, as the user ID and password are passed over the network as clear text (it is base64 encoded, but base64 is a reversible encoding), the basic authentication scheme is not secure. HTTPS / TLS should be used in conjunction with basic authentication.
Bearer authentication (also called token authentication) has security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.” The bearer token is a cryptic string, usually generated by the server in response to a login request. The client must send this token in the Authorization header when making requests to protected resources:
Authorization: Bearer < token >
Note: Similarly to Basic authentication, Bearer authentication should only be used over HTTPS (SSL).
For more information link1, link2