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
Related
I'm learning about Basic Authentication and Jwt Authentication with Java and Spring and I want to ask you if basic authentication is a session based authentication?
I know that in a session based authentication, when the client log in, a sessionId is stored in cookie on the client browser and after that when the client make another request, the server compares the sessionId with the data stored in the memory of the server. And also I want to ask you how is the sessionId sent from client browser to server? Is it sent in the header like a token or how?
And the last question is how the server validate the Jwt token? I know that in case of session authentication, the sessionId sent from client is compared with the data from the memory of the server. But what's happen in case of Jwt authentication? The token is sent with the header and I know that the server validate it and there is no data in the memory of the server. Then how the server compares the token? Any feedback will be apreciated! Thank you!
if basic authentication is a session based authentication?
I know that in a session based authentication
well then why do you ask?
Actually - basic authentication means, that the user credentials(username and password) are sent in the Authorization http header
Authorization: Basic base64(username:password)
The server may or may not use a session cookie. Session cookie may be used with other authentication means or even without any authentication
how is the sessionId sent from client browser to server?
As a session cookie A session cookie is sent as an http header which browser treats as session-persistent
And the last question is how the server validate the Jwt token?
The JWT token should be signed. Note the token has usually 3 parts
header.body.signature
the header specifies a signature type (an asymmetric key or shared secret) and the signature is authenticated (signed or hmac-ed) header and content.
So - the server must validate the issuer, expiration and the signature.
So the server (service provider) doesn't need know the client's identity upfront. The service provider needs to know the issuer's (authentication service which issues the jwt token) public key or shared secret key.
After the jwt validation the service can assume the caller's identity based on the information in the jwt token.
why Jwt is more recommended?
It depends in the use case. (everything has its pros and cons)
I'd recommend using jwt in a distributed and/or microservice architecture. The service doesn't need to access the credentials or to authenticate the user.
In the basic authentication we need to send the username and password for every request.
In the session authentication we will send username and password at initial request. Then from server response we get the session id which stores in browser and gonna use that for requests.
In the token authentication we will send username and password at initial request. Then from server response we get the token and gonna use that for requests.
hope u got it!!
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.
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 have a service that I would like to access from cURL and browser on which is enabled LDAP Basic Auth. But this service is a backend of a proxy on which is enable another Basic Auth.
So to reach my service my request has to send two different Basic Auth headers. Is that possible ?
It's possible to authenticate against your application and against a proxy in the same request.
Authorization header
To authenticate against your application, use the Authorization HTTP header:
4.2. Authorization
The Authorization header field allows a user agent to authenticate
itself with an origin server -- usually, but not necessarily, after
receiving a 401 (Unauthorized) response. Its value consists of
credentials containing the authentication information of the user
agent for the realm of the resource being requested.
Authorization = credentials
If a request is authenticated and a realm specified, the same
credentials are presumed to be valid for all other requests within
this realm (assuming that the authentication scheme itself does not
require otherwise, such as credentials that vary according to a
challenge value or using synchronized clocks). [...]
Proxy-Authorization header
To authenticate against the proxy, use the Proxy-Authorization HTTP header:
4.4. Proxy-Authorization
The Proxy-Authorization header field allows the client to identify
itself (or its user) to a proxy that requires authentication. Its
value consists of credentials containing the authentication
information of the client for the proxy and/or realm of the resource
being requested.
Proxy-Authorization = credentials
Unlike Authorization, the Proxy-Authorization header field applies
only to the next inbound proxy that demanded authentication using the
Proxy-Authenticate field. When multiple proxies are used in a chain,
the Proxy-Authorization header field is consumed by the first inbound
proxy that was expecting to receive credentials. A proxy MAY relay
the credentials from the client request to the next proxy if that is
the mechanism by which the proxies cooperatively authenticate a given
request.
Basic Authentication
For more details on the HTTP Basic Authentication scheme, check the RFC 7617:
2. The 'Basic' Authentication Scheme
The Basic authentication scheme is based on the model that the client
needs to authenticate itself with a user-id and a password for each
protection space ("realm"). [...] The server will service the request only if it can validate
the user-id and password for the protection space applying to the
requested resource.
[...]
To receive authorization, the client
obtains the user-id and password from the user,
constructs the user-pass by concatenating the user-id, a single
colon (":") character, and the password,
encodes the user-pass into an octet sequence,
and obtains the basic-credentials by encoding this octet sequence
using Base64 into a sequence of US-ASCII
characters.
[...]
If the user agent wishes to send the user-id "Aladdin" and password
"open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
[...]
Your cURL command line would be like:
curl -X GET \
-H "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" \
-H "Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==" \
"http://example.com/api"
Important! Please note that the name of these HTTP headers are unfortunate because they carry authentication data instead of authorization data. Anyways, these are the standard headers for sending credentials in HTTP.
I've read articles and seen example projects. I know owin allows to decouple application from web-server specific code, oauth allows third party clients to get access to application resources, and bearer token - client can get security token by login and password and use it as key for access to application resources.
I know that for simple cookie authentication using owin it's enough UseCookieAuthentication. But owin has this extensions: UseOAuthAuthorizationServer, UseOAuthBearerAuthentication, UseExternalCookieAuthentication, UseOAuthBearerAuthentication and I don't understand the full picture.
Could I use oauth without oauth bearer token (does it make sence)?
What are use cases for external cookie?
What are use cases for oauth (is it required only in case of client and server work in different domains using some api)?
What are use cases for oauth bearer token authentication?
Is it required oauth and bearer token authentication for web api only and for classic asp.net mvc applications it's no need?