Which of the authentication methods above is considered to be better and why? The purpose could be for performing a GET/POST request.
One major benefit is that OAuth works a bit like a valet key - you can authorize an app to work on your behalf without giving it your personal password, you can revoke its access without having to change your own password, etc.
http authentication is not encrypted. Oauth uses an authentication server to securely log in over https therefore it is more secure.
Related
Problem:
I want to create a webapp with VueJS and a custom backend with NodeJS (ExperssJS and PostgreSQL). It should be possible to login with a username and password. After a successful login, the user can access secured endpoints of the ExpressJS server.
Now I am thinking how I can securely authenticate HTTP requests after a successful login.
What I consider doing:
Using a JWT and providing it in the authentication header of every request.
When the user provides correct login data, the server creates a JWT and sends it as response to the client. The client stores the token and adds it to every HTTP request as the authorization header. Because the transport is secured with TLS (HTTPS) the token should not be visible while transporting. To provide a seamless user experience the token has to be saved at the client side, so the user does not have to authenticate for each request.
So my question is: How can I securely save a JWT token for further HTTP request authentication?
Possible options:
LocalSotrage - BAD IDEA! (not really secure)
Cookie - more security (but also not perfect)
Last thoughts:
Isn't there an "absolute secure" or a "best practice" method to handle authentication for such a scenario?
P.S. I am pretty new to this field, so please forgive me if i wrote something stupid :D I am also aware that there are a lot of tutorials on how to setup something like this, but what i want to know is, which technique is the best and most secure one.
Thanks in advance!
PassportJS also support using local strategy. You might want to take a look about it. here
If you are new then it's better to use already build user authentication flow like Google login, Discord Login etc.
There is a well known library called Passport JS which makes third party login system integration a breeze.
I'm developing a MEAN stack application, and I'm currently setting up an account system. I've seen several tutorials about Authentication, all using JWT.
I am wondering if, JWT could be used as way to secure communication transport over non-secured connection like HTTP?
I've set up HTTPS to communicate from my Angular 4 front-end to my NodeJS + Express back-end, and thus, wondering if JWT are necessary to secure my communications?
JWT should not be confused with encryption. From jwt.io:
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a
compact and self-contained way for securely transmitting information
between parties as a JSON object.
The JWT is signed with public/private key pairs so the sender can be verified, and verified that the payload has not been modified. However, the JSON Web Token is in clear text.
var token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ";
var payload = token.split('.')[1];
console.log('Payload: '+atob(payload))
Below is a figure from jwt.io showing the authentication flow when using JWT.
You need SSL/HTTPS to encrypt the communication. Without SSL/HTTPS attackers can sniff the network traffic and obtain the JWT, hence your application is vulnerable to man in the middle attacks.
Is JWT necessary over HTTPS communication?
No. Communication protocol (HTTP v.s. HTTPS) is one thing, and authentication mechanism (JWT v.s. Session) is another -- these are 2 totally different area.
For communication protocol (HTTP v.s. HTTPS), HTTPS can be used alone, without any JWT tokens or sessions. For example, a static web site can be made (only HTML+CSS) and served with HTTPS. In this way, the web site can be certificated by CA and prevent forge attack.
Even if you need authentication in web application, JWT token is not the only choice. Session is old technology but it is still reliable, which made JWT definitely NOT necessary.
No, JWT is not required when your server supports HTTPS.
HTTPS protocol ensures that the request & response are encrypted on the both(client & server) the ends.
I believe you would want to send across user credentials in every request to the server, and in turn server validates the user before sending any response from the server.
Although you can do the above, but on the server-end, you would end up validating user credentials against a Database in every request which is a expensive task, you can avoid this when you use JWT.
JWT basically authenticates a user once & issues an access token which could be valid for a duration of time.
Nowadays developers prefer Token-Based Authentication instead of Session. Token-Based Authentication has lots of advantages over Session.
We use JWT i.e. JSON Web Token to generate a token after user authentication, every time your front-end app makes an API call so your system should check whether the request has a valid token or not if it is there and it is valid then it is considered as the valid user.
In short, we use JWT to validate our API calls it is nothing to do with HTTP or HTTPS
I'm new to JWT. Here is my scenario of an attack of JWT when it's in the http instead of https. Suppose a JWTa is issued to userA for accessing resource A on the server. A hacker is also a legal user of the server, he got JWTh to access resource H. Without the https protection, the hacker can sniffer the network and get the JWTa in the http header from A's request and put it into the hacker's request. Since JWTa is a valid token, so the hacker can access resource A. I guess the JWT protocol can prevent this, but I don't know how. After the signature is verified, the claim also needs to be verified. Seems the "aud" can prevent this, but I don't know how it works exactly.
I read in many places that basic auth is not secure over http connection because client's password can easily be derived from the encoded value. But if that is the case, then is oauth 2.0 secure over http?
In oauth 2.0 after the browser receives the access token, it appends the token to all the request made to server. In that case if someone gets hold of the access token, although they cannot derive the password from it, they can still use this access token to make requests to server masquerading as the user.
If this is not the case , then can anyone please explain where am I wrong and why is oauth 2.0 considered more secure than basic auth over http connection?
P.S: The scenario I have used in above example is related to client logging into an application using his username and password
Using OAuth 2.0 over plain http is insecure and is prohibited by spec: https://www.rfc-editor.org/rfc/rfc6750#section-5.3 which says:
Always use TLS (https): Clients MUST always use TLS [RFC5246]
(https) or equivalent transport security when making requests with
bearer tokens. Failing to do so exposes the token to numerous
attacks that could give attackers unintended access.
Then again, the reason that OAuth in general is considered more secure than basic authentication is because OAuth 2.0 tokens inherently have an expiry associated with them whereas basic authentication does not. So losing a token to an attacker would at least restrict the attacker in the time window that it can be used.
I have a load of api endpoints that I want to protect from CSRF. I'd like to do this in a stateless way, so naturally JWT comes to mind.
The problem is, these endpoints do not require the user to be logged in.
So, my problem is, I can use JWT, but I have no way of verifying the token on the server side -- I have no logged in user I can match it to.
Is there any way JWT can be used in such cases?
CSRF is only a problem for requests where the browser implicitly authenticates the request (cookies or basic authentication). But if you do not have any authentication, any site could potentially call your API.
So if I understand you correctly, you are looking for a way to make sure that the request to your API is coming from your web application.
Take a look at the client credentials grant in OAuth 2.0. It basically issues a token to authenticate the application instead of the user.
I'm looking at the oauth implementation twitter proposes here:
https://dev.twitter.com/docs/auth/oauth
and oauth libraries like signpost:
http://code.google.com/p/oauth-signpost/
they both talk about using the client secret during the oauth flow, which means for my client application, I'd need to store the secret in the application itself. This is probably risky as someone could grab the secret out of my app. Are there any methods around storing the secret within my app? Am I misunderstanding the oauth flow?
Thanks
There are no ways of storing client credentials in a native or JavaScript application without making them practically public. Also, putting those credentials on a proxy server and having the client talk to the server (so that the credentials are not exposed) doesn't really solve anything either. Now you have a problem of authenticating the client to the proxy.
The right solution is to have special support for native applications provided by the OAuth service. OAuth 2.0 uses pre-registered redirection URIs and other techniques to accomplish a reasonable client identity verification for such clients.