Here is how my application should work:
Users can use some functionalities of my application if they have enough chips (token) which they can buy from another application, or they can be granted to them upon some event, whatever.
Users have an attribute associated with them called 'chip', which represents some number. This information should be represented as a claim, probably.
I want Keycloak to do this authorization for me - to check whether user can use the functionality or not. I've come across JavaScript-based policies. It's seems they are able to operate on informations in tokens - like user email etc, but this is not my case where token can contain obsolete information, i.e. when token was generated user had enough chips but since then he spent them.
Maybe token should be refreshed upon spending chips, but in that case, would it be updated with current informations bound to user? Or maybe authorization service can somehow access database during evaluation of a policy? Could this work or are there any elegant solutions to this use case?
Keycloak is not here to check if the user has enough money. Keycloak is here to say if the user is authenticated and if he has the roles for a certain application (admin, user...).
Checking if the user has enough money should be on server-side. For an incoming request, you have to check in the database if the user has enough chips to access the application and if he hasn't you return 403.
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/
Iam working on a flutter mobile application where i use Google SignIn for Auth, is there a way to authorize users with existing account only?
Prevent users from creating new accounts? I've looked for the same thing without finding a way to do this with any Firebase project setting.
The solution, I believe, is consider the difference between authentication and authorization. Firebase's Authentication service is aptly named. It does authentication
- validates that a user is actually who they claim to be. It does not do authorization - control what actions authenticated users are allowed to perform or what data they can access within an application. App developers have to be responsible for managing user authorization.
One way to do this is to maintain a collection of "authorized users" in Firestore, for example. When a user authenticates, your app would perform a lookup to see if the current user is actually authorized or not. Security rules can be written for Firestore and Firebase Cloud Storage to also validate that the current user is in the "authorized users" collection before allowing access to data. But this requires extra data queries to obtain this authorization info.
The authorization method I prefer is to use Custom Claims which can be assigned using the Firebase Admin library. A custom claim can be added to an existing user account that can act as a flag indicating what type of authorization they're granted. Front-end code can check the authentication token they've been issued for the custom claim to determine the authorization they've been granted. Server-side code and security rules can also check for those required custom claims within submitted requests.
Realistically, any application you build where different users might have different levels of access will require you to deal with authorization. I believe that assigning carefully thought-out custom claims is the best solution.
I apologize if this has been answered, but I have been searching for hours, and still don't quite understand. This is a specific question, and not a "which is best" question.
Specific questions are in italic.
I have created a RESTful API, which was at first meant to be completely open. However, the organization has now decided to create a first-party mobile app to consume and (to some degree) update the data.
I am investigating authentication frameworks (oAuth2), and was not sure if oAuth2 was the correct way to go to meet our goals. And, if it is, which Authorization Grants applied to which set of users.
Our goals are:
To allow users to login and create accounts in the first-party app, entirely through oAuth 2 providers (twitter, facebook, google). These users would have access to the greatest set of data via the first-party app.
Assign different roles to the users (admin, moderator, etc).
Allow other applications to register, receive token credentials, and have limited write access or expanded access to the data. This would open them for creating third-party apps or research systems.
Finally, we would like to keep some of the data completely open, with no authentication needed.
So, am I right in assuming that we want to setup an oAuth2 *Server* (Authorization and Resource Server)?
If so, which Authorization Grants apply to the above situations?
One last question: For users using the first party app, would the app be responsible for logging them in and keeping their access credentials? The API server serves NO html, and is 100% RESTful. Does it need to serve login forms?
If you need to both authenticate and authorize users to your API based on various OAuth2 social logins, you do need some kind of API server or service where you can define your users and groups/role and the scopes that are available to users based on your rules.
Some cloud-hosted options for this are:
Auth0
Firebase
If you integrate with a service such as the ones above, you can let the service take care of authenticating users and just make sure that every user call checks against the service first for permission before it goes ahead and does anything.
I want to make a simple REST web app, where the user interact with the objects through links in an email. The links have a token that can be used to authenticate a user without a username and password, like the ones that are usually used to reset a password.
What are the best practices for such a login-less, token-based authentication system?
I am by no means a security expert.. but some of the points which come to mind are -
Lifetime - The token should expire after a set period of time. Indefinite access using the token certainly doesn't make sense.
Replay attacks - The mechanism should prevent replay attacks.. which means the token should be valid for not only a set period of time, but also fixed number of calls.. Ideally exactly 1. If this number is not exactly 1, then it opens another can of worms..
Unless, its a feature :( For example, by design, the user is expected to share link with others, and anyone with the link should be able to access the resource in question.
Authorization - Granularity of the access granted by the token. Is it black and white.. or is the token also associated with a fixed set of rights. For example - token X was issued for Read-Only access, vs token Y was issued, for same resource with R/W access.
Administration - User / Admin should be able to see and verify any currently active and issued tokens, and associated information (permissions granted / affected resource etc), and explicitly revoke them, if necessary.
Secure Communication - You should consider security of the medium through which the url with token will be sent to the user. i.e. in your scenario, do the users receive emails over secure channel (TLS / SSL)? Should the email itself be protected with DRM?
Man in the Middle / Leaks - Similarly, even though you are providing the url in email, and the user is not logging on using user name and password over SSL, the resource should still be accessed using the url with token over SSL. This will prevent any capturing of the tokens from url, by a man in the middle. You would also need to be very careful about when the users browser may use this url in places you didn't expect..
I can vaguely recall reading about a popular site being affected by their urls being used as Refer Url, when displaying ads on their website.. which means, the advertisers site would probably get the url with the token as Refer.
Generation - Choice of algorithm to generate the token - May seem pretty obvious, but the token should be extremely obscure and near impossible to guess or brute force. The tokens should never be reused and the algorithm should avoid collisions.
Server Side Security - The tokens should probably be treated with same security as you would secure users id and password. If your user database gets hacked, hackers should not get the users passwords and other sensitive information.. Similarly, if your user / resource / token database gets hacked, despite the expiration on the tokens, hackers should not be able to access the resources as users for x hours.
Point is, when the tokens are stored on server side, they should themselves be secured / encrypted.
On the same lines.. just like its bad practice to log information like passwords in log file (specially plain text), You'd also have to consider any place these urls may get logged (plain text) on your server.. For example web server logs. If only super admins should have access to user's database, then they should also be the only ones to be able to see these token.. Not your web server admin and not any hackers parsing the log file after the hack.
Auditing - If there will be a need for auditing, you'd need some mechanism in place to prove that while the user didn't log on to the system, they are indeed the ones who performed the action / operation in question. Would you want to track the ip address and other information along with the request which would help such auditing?
Consent - Do your users even consent to the use of such alternate means of authentication and authorization? Should this be an optional / opt in feature?
EDIT: I found a link to the referrer url problem I was recalling. Although it was in context of user information.
I agree to 10 points of Vikas however from security perspective I have to tell you few points that you must be careful.
I will try to keep as simple as possible. And here I simplify the technical stuff to your special case.
Firstly tokens are used to prevent Cross Site Request Forgery attacks (XSRF). Keep that in your mind. If there is a web platfrom without unique tokens on the forms then any attacker can force the user to make malicious requests.
If you simply try to authenticate the user with a token, this is pretty wrong. Because there must be no simple authentication process and you can not rely on token.
Here is how the login system works in official security documentations, im writing as I remember:
Identification: you have to identify the user firstly, that is generally done with username. YOu will know that there is a user exist in your system.
Authentication: Let's say you have already identified that user A want to login. So you mast authenticate the user A with something that you know and user A know. We call it password simply :) You cannot by pass this step with plain text methods. Passwords are generally encrypted in your db and also through all communication with secure certicates, check ssl.
Authorization: okay you made the authentication somehow, the user has a right to get Authorization. Let's say if the admin type user is logged in, he has differen rigts and if the normal user is logged in then she has regular rights.
Session control: finally you have to control the session with a secure way. Here generally in web applciations people use access tokens for all requests to be sure that the authorized user is aware of the request. As a platform owner you are responsible to secure everything until the session ends. If you don't satisfy the users with your security, then probably your platf is not going to survive longer.
Tokens have different lifetime to expire and different access rights.
Now let's look at what facebok like companies do with mobile aplications. For the mobile app they generate a unique access token which is alway alive. One shortcoming here is, if any attacker steal the mobile token generally she can do anything in the account anytime :) Anyway here our point is how they verify the users with those tokens; firstly the token is unique for that device. (Actually not exactly unique or not dependent on hardware, because if you clearly steal the necessary files from the device then you can use it on another phone). So with this unique access token which is generated with users password at their initial login on mobile app, they can login always automatically with that. And this method is a little similar to what you want to do. However pay attention that they don't authenticate the users with links or email code.
Verification is not an authentication, don't forget that. By sending e-mail you can verify the users if the emailed code is unique and valid for only 30 sec or 1 minute. I hope you got the point.
Here I suggest you to check single sign on across multiple domains, which is really interesting.
Single Sign On across multiple domains
Let's say you are logged in to google.com and then you visit the youtube.com Opps the youtube is already logged in? Yea, cool right, but exist for long time. They can authenticate users accross domains which use different cookies with a little and secure trick. You will read on the link.
If your service is not really confidential and if you want to make your users happy with easy login system. Here is two of my solutions which I love :)
1-) Ask users their email address: just directly send 4-6 digit code as e-mail. Ask user the enter/click on that. There will be no password at all, only unique code on each login.
2-) Let's say you need to verify the user with a stronger way than email. Then mobile phone :) Here trick is; you will not send the verification code to user, but they will send what you tell them to you.
Ask to user to send a SMS with a unique CODE to XXXXXX your number :) Connect your mobile operator with your web service and check whether the code is sent to you by the user :)
There is always a trade-off between security and simplicity, and also with complexity. You have to find the balance.
Don't try to make it simple if your security is going away.
Don't try to make it complex if it'll seem more secure.
Hope those informationn help you.
I am building a messaging application using BackboneJS which naturally persists using a REST interface.
The issue I'm having is that I don't know how to restrict what data a user can pull back from the API. For instance a call to /messages would, at the moment, return messages for ALL users. I would like that resource to only return messages belonging to the current user.
Searching online seems to indicate that oAuth2 is the best way to solve this issue but all the tutorials talk about been redirected to another place to confirm access and retrieve an access token.
Given that my users will have already logged into the message application and that the REST API is actually part of the same application I don't like the idea of asking the users to confirm that my own app can access my own API.
Is there a better way?
oAuth2 is probably your best bet -- you definitely don't want to roll your own security. However, the flavor of oAuth2 you are thinking of is probably not what you want.
oAuth2 has four different flavors, known as authorization grant types:
Authorization code: This is the type you are thinking about. It is often called three-legged oAuth, because there are three actors in the token granting process (app, resource owner, and user). The app asks the user whether it is ok for the resource owner to give specific type(s) of access to the resource. It is a rather complex process that allows the validation of user credentials without allowing the app access to them. This is not necessary in your case, since you are both the app and resource owner.
Client credentials: This is a method for authorizing a client application with the server. It does not use user credentials at all. If you completely trust your client application (all client applications) to correctly protect user data and not expose other user's data to the user using the app, or you are providing only non-user data via the API (for example, map data or catalog data), you might be able to use this fairly simple type of oAuth2. However, if you want to be vigilant in protecting user data (and not allow apps to get to the data without the user providing credentials), you might not use this one.
Resource owner password credentials: The username and password of the user is passed via https to your backend server, which authenticates and authorizes access by providing an access token. The access token can then be passed with each call, and it remains valid for accessing the backend until a configurable time period has elapsed. This means that someone intercepting the token could only use it successfully for a limited amount of time (some number of minutes, generally). The interceptor would not know the username and password of the user. In addition, you can supply the app with a refresh token, which can be used to get a new access token once it has expired (until the refresh token expires -- usually with a significantly longer expiration date). Since the credentials are not passed across the wire often (and must only be passed encrypted), this is often the best solution for protecting user credentials and not requiring the user to pass them in often (good user experience). Implementation is much simpler than for the authorization code grant type.
Implicit: This is the least secure method -- no credentials are validated server side at all. This is usually used for client side scripting languages where credentials cannot be stored safely. If you are worried about security at all, avoid this type if possible.
So, check out OAuth 2.0, and look for the resource owner password credentials grant type.