As the title suggests, I'm trying to implement the mechanism of retyping the password again before proceeding any critical action, e.g. change email, deactivate an account, invites a new user, ... etc.
The problem is, I'm confused about how it should be done in the REST world.
Should it be like, first, use the password to authenticate the user, but with a different backing authentication made especially for this action and use the resulted token to access this protected resource later? E.g. a JWT token with a specific claim for this action and guard that endpoint with this custom authentication to authenticate for this custom token?
Or should it be done in one request providing the password and based on password check the action will be proceeded or denied?
Or should it be something else?
Thanks in advance for your help, I really appreciate it.
Note: I'm using DRF that's why I added it's the tag to the question, but as this is a general question
Related
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/
I built a simple authentication system for my backend API with Express using Cookie-Parser and/or sending the Token to the front end.
It works like this: the user makes a post request to the login route with the username and password, and if it matches, he gets back both a .json response with the token and a cookie set with the token.
I thought it would be nice for the frontend development and authorization purposes to have the current user available in every successive request after the login. So, I set a middleware that searches if there is a token, tries to find a user in database with the corresponding ID, and set the user info (without the password) as a parameter in the request object (req.user).
What I wanted to know is:
Is it a bad practice to put the user info in the request? Does it lead to security problems? Or maybe the database query in every request could overload the server if the app scales to much?
This is my first backend API, I'm trying out different ways of doing things, but I'm not aware of the best practices in the field. Any help is very much appreciated!
That is why there is encryption and in this context it is an ssl ticket. If you add login details to the request you NEED to make sure that the http response is encrypted. Once it is encrypted it is ok to do what you are doing. If it is not, an eaves dropper can snatch up that data from sniffing on your network.
I checked a lot of tutorials and examples of jwt, for example, if you google "spring-security jwt example" you will probably see those links:
https://www.callicoder.com/spring-boot-spring-security-jwt-mysql-react-app-part-2/
https://dzone.com/articles/spring-boot-security-json-web-tokenjwt-hello-world
https://www.javainuse.com/spring/boot-jwt
Question) Their authFilters use UserDetailsService, so they fetching data from Database as it just a Simple Token, and not JWT.
So I think I don't understand something.
UPD: what I would do:
Or create my custom Authentication and custom AuthProvider.
Or just use JwtUtil class which will decode jwt and then create default UsernamePasswordAuthToken and set it into SecurityContextHolder.
After another review, I noticed, that I missed important note in Rajeev Singh's tutorial on callicoder
Note that, the database hit in the above filter is optional. You could
also encode the user’s username and roles inside JWT claims and create
the UserDetails object by parsing those claims from the JWT. That
would avoid the database hit.
However, Loading the current details of the user from the database
might still be helpful. For example, you might wanna disallow login
with this JWT if the user’s role has changed, or the user has updated
his password after the creation of this JWT.
I have read the issues about impersonation, and from what i could find so far it can be achieved. I'm not sure tho if the following could be done using it.
A user doesn't have permission to do a certain operation, but it can be done if a supervisor grant him access.
The grant would be only for that operation/request.
is this something that can be done using impersonation, or there is a better approach for this?
Thanks in advance.
Quick brain dump of what you could do: You would have to implement this yourself in the user service in IdentityServer. One approach is to pass a custom param in the acr_values from the client with the ID of the user you want to impersonate (you will also have to pass prompt=login to force the request to go to the login workflow and thus the user service). In your user service implementation in PreAuthenticate you can check if the user is already authenticated, the custom acr_values is present, and the user is allowed to impersonate the user being requested. You'd then assign the AuthenticateResult on the context with the identity of the new user. This short circuits the login process and will return back to the authorization endpoint, and then back to your client app.
Our application has different roles for each user and only certain users are allowed to query the data. We have to validate user id and password for each request.
I have a simple REST get where the user passes employee id and we return employee data. What is the best way to pass userid and password? Is using userid and password in URL (i.e. #PathParam) bad idea?
Right now I have it as follows, this will return the employee data for emp id 111 by user u1
https:../MyRestWebService/services/getEmp/u1/encpassword/111
Only https port will be open in the firewall i.e. all requests are always over https and password is always encoded string (we publish how to encode)
thanks
Whether or not this is a good idea always depends on exactly how you are using it. Passing the password itself will probably raise eyebrows at least, and it could be a serious problem.
Generally, the two approaches are require a login prior to issuing further calls, which mimics what a human user would use the system but requires logic to handle logging in and out on the client side. The second is to use API tokens, which is potentially less secure, but more convenient for automated clients. Note, there's no fundamental reason you can't do both.
Take a look at how github handles API authentication; they actually do both. You can do an OpenAuth authentication to create an authenticated session, which takes the form of a temporary access token used in subsequent requests. You can also create a permanent access token and associate it to the account.
https://developer.github.com/v3/oauth/
https://developer.github.com/v3/auth/#basic-authentication (see x-oauth-basic variation)
You can also use a framework or built in support for sessions (depending on your server stack) to track authenticated sessions implicitly.
Yes, putting username and password in the URI is a bad idea. For starters, it means you can't share the URI without exposing your username and password. Is there some compelling reason you aren't using HTTP Basic Authentication? This seems like the exact case it's designed for.
GET https://.../employees/111
is a much more correct URI.