I am creating JWT token by using username and password, it will get the JWT token as expected, But my one of the use case will create JWT token based on specific IP address. Let me know anyone has ideas to resolve this one?
It works when each user has a static IP address. You can create a JWT with that IP and assign it to each user and later accept requests which have correct JWT. You should be aware of some attacks like IP spoofing. There are some methods like SSO which can be a better option for organization authentication/authorization.
You can check this page JWT Data Validation. Pay attention to JWT_CREATED and JWT_DECODED events, I think it's just what are you looking for.
Related
The issue I have with JWT tokens is in the event the token is stolen. Now I have a session that is linked to the token in the back end. I do save the user's IP address when the token is first generated.
The issue is that, because of mobile phones and cellular networks, the IP can change while the end user is using the web app, so I cannot enforce an IP verification. I do a UUID check but since the UUID is passed with the token, obtaining the token also means obtaining the UUID.
Is there any way to secure JWT tokens for the case they get stolen?
Yes, there is a way to protect tokens from being used by a malicious party. There is a concept of "sender-constrained tokens". These are access tokens which require the sender to present some kind of proof of possession of the token. Such a token, is no longer a bearer token, meaning that it can only be used by the original client, not by anyone who manages to steal that token. There are different way to implement sender-constrained tokens (sometimes also called proof-of-possession tokens). E.g. you can use mTLS constraint, which is reliable but a bit harder to implement, or a standard called DPoP - Demonstration of Proof-of-Possession. The latter one doesn't require you to deal with Public Key Infrastructure.
I am currently developing financial services as a personal project.
In order to strengthen security in the project, it is designed and implemented to process authentication at the gateway stage using AWS API Gateway.
I tried to log in using a mobile phone number and the received authentication number, and I don't think this is appropriate for Cognito and IAM identifiers, so I'm going to run the Node Auth Server that issues and verifies JWT tokens in AWS Lambda.
In the process, I tried to include an identifier such as user_id or uuid in the payload of the JWT token, but my colleague opposed it.
His opinion was that access token should only engage in authentication and that the token should not contain a user identifier.
I agreed with him to some extent, but if so, I wondered how to deliver the user identifier in an API such as "Comment Registration API".
Should we hand over the user identifier along with the access token to the client when login is successful?
in conclusion
Is it logically incorrect to include the user identifier in Access Token's Payload?
If the answer to the above question is yes, how should I deliver the user identifier when login is successful?
I wanted to hear the majority's opinion, so I posted it.
Thank you.
Typically you want enough information in the access token so that you can also do proper authorization about what the user/caller is allowed to do.
Typically, you separate authentication and authorization like the picture below shows:
So, to make an effective API, you do want to avoid having to lookup additional information to be able to determine if you are allowed to access some piece of data or not. So, I typically include the UserID and some other claims/roles in the token, so that I can smoothly let the user in inside the API.
However, adding personal information in the access token might have some GDPR issues, but sometimes it might be necessary to also add. But I don't see any issues adding information like UserId and roles in the token.
Yes it is logically correct and a normal thing to do. To see how to do it in a Node Auth Server, you can look at this: https://auth0.com/blog/complete-guide-to-nodejs-express-user-authentication/
For token based authentication for any service, first we have to send username/password in the request. Doesn't this cause security issue? How can we overcome this security issue of passing username/password?
The initial request which contains the username and password is no more or less secure than subsequent requests which would instead be bearing some sort of token. The solution to this problem, really to sending any type of information across the network, is to use two way SSL/HTTPS. With HTTPS, information being sent gets encrypted on the client machine, and then (in theory) only the server would be able to read what is contained. So, sending the plain text username and password might seem insecure, but if using HTTPS, then in fact it is secure.
I am going through various javascript/auth tutorials -- I understand salting password and storing it in the DB, using Passport, generating the token and storing it in the request header, etc. Overall, I got the whole flow going -- for signing up and signing in. But I am not sure why the following is not being mentioned in any of the tutorials: if I can view http traffic on the network, cant I steal someone else's token and "impersonate" that user? I wont be able to decrypt the token since I dont have the "secret phrase" used to generate the token, but I can surely take it "as is"?
So, do tokens and https go together? Is my understanding about user impersonation via a token correct? Thank you
As somebody who intercepts a JWT you ...
... are able to "decrypt" the JWT since it is not encrypted. It is only Base 64 encoded,
... can validate the signature if an asymmetric scheme is used and you know the public key,
... can use the JWT to impersonate the user,
... can not change the claims made in the JWT since then the signature would no longer be valid which would be noticed by the server.
So, yes, use HTTPS.
Also on the server side don't rely on the JWT alone. Check that ...
... it is not on the blacklist of revoked tokens (you have such a list, don't you?),
... the request is coming from a network address that is a claim in the JWT (you include the network address for which the JWT was issued, don't you?.
I'm in the middle of writing a RESTFUL API in Hapi, I could not figure out API authentication methodologies.
Assuming we're using SSL/TLS with HTTP/1.1, why do we need something like JSON Web Token (JWT), where we already have HTTP Basic Authentication. We may protect every endpoint with HTTP Basic Auth, so we wouldn't even need login routes like '/login'.
So, what's the point of those authentication schemes, OAuth's and JWT?
Thank you.
OAuth and JWT use tokens, not passwords. Tokens are uniquely generated per application and site. If someone steals a token, they have not stolen your password, and that token is only good for that session only.
Contrast this with basic auth, it's an actual user password. Not only can they re-use that password whenever they want, they can also use that password with any other service that uses the same password. Stealing a token doesn't allow that to work.