Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed last year.
Improve this question
Cheers,
We started implementing biometrics authentication in our web system and came to a doubt. We're going to use a third-party solution for performing it which is going to be called via a web service.
There are going to be four kinds of authentication:
Regular one: username/password
Challenge
Fingerprint
Cellphone
All users will be authenticated using 1. Optionally, some of them may also require 2, 3 or 4. What would be a good way of verifying which authentication type is required for a specific user?
This is something new for me. Initially, I thought about passing the username from the login page to a web service, which would query the database to check which authentication type is required for this user. Then, depending on the result, the second authentication form would be shown on the screen. Obviously, some extra check would be performed after the user hit the Submit button.
Am I on the right path, or there are better solutions for this?
Thanks,
I guess that would work. Maybe it is an option to do some sort of query in the background (AJAX?) when the username is filled in, so you can dynamically add extra inputs to your login form.
However, this has one potential issue: everybody that knows someone 's username can find out what authentication is required. If that is not wat you want, maybe just ask for a username + password to login to a reduced privelege mode. Then, as you suggested in your question, this reduced privelege mode may require extra credentials to continue to the more secure environment.
You could even make it so the reduced privelege mode will grant access to some of the features, while others require extra authentication (for example: posting a mesage would require basic auth, changing passwords might require all four).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 days ago.
Improve this question
I am currently in the process of designing a network of servers and databases for a project.
One key aspect of this project is the implementation of a central authentication server which will utilize session IDs to track sessions. These session IDs will be stored in cookies and sent back to users upon successful login.
Note: I understand that nextjs can work as both a front end and a back end. For reasons I will not get into here, nextjs is being used as a front end, and a separate central authentication server is being used for authentication. There are other servers/databases that will store data that users can access if they have proper permissions levels.
In step 1, I have no questions.
In steps 2 and 3, when the cookie is sent back to the nextjs server, what is the best practice for nextjs to determine the authorization level of the user?
I believe it's important that...
- Nextjs should know what navigation tabs to show, etc., when it renders the page for the user.
- Nextjs should also know what pages the user is allowed to visit. If the user is asking for a server-side rendered page that it isn't allowed to visit, it should be blocked
Possible option: Here, do I include some sort of JWT with authorization levels? It is my understanding that nextjs may be able to read these JWT authorization levels in middleware, then deny certain page requests that the user has by reading the JWT each time they request a page. Perhaps, even without middleware, functions could be used within the pages that would run server-sided, checking the JWT permission levels. Note that, in order for the nextjs server to know what the authentication levels are for the user, the tokens would have to be created in the central auth server, and then sent to the nextjs server.
Side thought: It seems that if I were to implement a function that checks the authorization level on a SPA, there would always be a way that a hacker could at least visit the blank page, correct? In other words, the only way to truly hide pages and navigation tabs from a hacker would be by somehow checking authorization levels server side (server-sided rendering), and then sending back a rendering of the page that only shows items related to the exact permissions of the user?
Overall, I would greatly appreciate any advice or insight on the best methods for authorizing users and limiting access to pages and tabs based on permission levels. While cookies will be used to store the session id and determine the data that users can receive when making API calls, additional measures such as JWT may be necessary for authorizing users to view specific pages. Is it common to utilize a combination of session/cookies and JWT for this purpose? What are the recommended best practices in this scenario?
Thank you for your assistance.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 months ago.
Improve this question
I am trying to make a custom API which uploads random numbers generated to my website page (to learn how API works). And whenever I want to see the page, I use my API key to do so. Can you help me in this? I am new to API stuff.
When creating APIs, there are lots of decisions to make. You could render your structure on the client-side and query your application server via RESTful API calls. Or you could have a server-side rendering approach and use your API internally. There are four main types of APIs:
Partner
Internal
Composite
REST
https://www.techtarget.com/searchapparchitecture/tip/What-are-the-types-of-APIs-and-their-differences
In your scenario it seems that you need to either choose an internal API approach or a RESTful approach.
Your random number function itself would be similar in both cases (a simple function written in the language of your choice).
However, the token usage largely depends on the type of your API.
You need to decide whether you are going to have usernames and passwords and is the purpose of your token only to avoid frequently logging in with very sensitive data, such as username and password, so, you use a token instead, which, if falls into the wrong hands, then they could not steal the identity of your users for good, as they are still not reaching these credentials. If so, then you will need to generate the token periodically. A way to do so is to generate it every week/month (whatever) and somehow send it out to your users. Or it could be generated whenever the user has to log in, sent to the user, who will be able to use that token from there on.
Or, you could separate the token from the login and provide a UI for the user where he/she can generate tokens while being logged in. There are quite many ways to approach this.
Otherwise, if there is no username and password and, there is a token and secret to identify the user, then you will need an alternative to the login. It could be a simple request for token generation. Or it could be a repeatedly generated and sent token.
In any measures, when you intend to run an API function as a user, then you will need to send the information that identifies your user. On most webpages this is handled by getting a session ID (that acts as a token) upon login and then, while the session exists, that session ID is always sent to the webpage, whatever request is being sent, this is how the website knows that you are logged in. Most webservers and programming languages that handle web requests also handle token generation and usage and browsers are in line with these through the cookies, which are small files that contain information for the website.
If you are having a custom environment or you prefer a custom token management, then of course you can implement your own.
But, if you want to achieve simplicity, then you could implement a register and a login feature for your API as well as the number randomizer, so these are 3 API functions for now, call the register when a user registers, store a 1-way-encrypted password, do a validation (like email sending with a token to the user) and implement token-based user validation, which is a fourth API function. So, the user:
registers
receives an email with a token
clicks on a link that has that token as a request parameter
once that page opens, store the user as an authenticated user and remove the registration token
This will enable logging in for your user. Once your user is logged in, a session ID should be generated (in PHP you need to look into the functions whose name start with session_, for example) and then using that session ID your API should make sure that the randomizer can be called and your UI should be designed in such a way that this feature could be found by users.
If I may, I advise you to avoid getting into your own token generation while you are learning, choose the simplest ways and once the simplistic configuration you have chosen is working reliably, then you may choose to write your own token logic if you prefer that for some reason.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have a legacy system that needs some tiny improvements to enable the system to run without interruptions. I got recently a security notification from Salesforce that there are some upcoming changes coming with the Winter ‘21 release that is going to have an effect on my system. The Secure guest user record access is going to start to be compulsory. By turning this setting on as a test prevents my system from working properly right now. The system has currently been set up to use the Visualforce page to access APEX scripts that make some business logic and even update/insert some data to Salesforce. That Visualforce page has been called from another system that runs totally separately. As much as I follow the upcoming Salesforce release makes it impossible to insert/update data in the way I have been currently doing. I realized I need to secure this with some kind of authentication so I can keep my system working when the Secure guest user record access option has been ticked. I want to add a user authentication for my apex script. I created a new Connected App and did the following:
Enabled OAuth Settings
Set OAuth Scopes Full access (full)
Set IP Relaxation to Relax IP restrictions
Exposed Apex Classes as REST Web Services
I have currently been using Salesforce Sandbox as a test. I created a new connected app and made a login call first. That all worked fine and returned me access token. I did make sure that I didn't have any sessions open when I called the apex script via the Visualforce page where I have defined a new apex:page. For some reason, my Visualforce page is always public and allows me access to everything without asking me any token.
After having done all this I can still get access to everything without doing any user authentications.
Can someone please advise me on this.
Here I am calling Visualforce page that in return calls APEX script:
HttpRequestMessage apiRequest = new HttpRequestMessage(HttpMethod.Post, restCallURL);
apiRequest.Headers.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));
apiRequest.Headers.Add("Authorization", $"Bearer {authToken}"); //check Bearer
It works fine even without me setting a token to it.
This is how my Visualforce page looks like:
<apex:page controller="TestGatewayResource" sidebar="false" showheader="false" contenttype="text/plain" action="{!action1}">{!StringCodeReturned}</apex:page>
This is my test Apex script:
#RestResource(urlMapping='/test_defined_type/*')
global class TestGatewayResource
{
String StringCodeReturned = ""; // very simplified to give an idea what I am doing.
#HttpPost
global static String activate()
{
// makes some work by calling other classes and inserting/updating data to Salesforce
}
}
Edit: I added more background information to understand better my issue. I also added some code samples. Tyi I have no more experience than a week working with Salesforce trying to figure things out.
(too long for a comment)
Your question is confusing, what are you trying to do? Connected apps are for API access (REST, SOAP) but then you write about Visualforce page, that's for normal browser-based access.
As internal user you'll have access to all VF pages (well, if you're sysadmin or your profile has them assigned). No connected apps needed. If you're external user (guest) you can still access a VF page if it was exposed on a Site. No login needed = no OAuth2.
With API access you need to make login call first (few ways to do it, SOAP or there are ~9 OAuth2 options to choose from) and then you'd access apex REST services for example (again, if your profile allows).
If you want to do programmatic screenscraping (pull html of VF pages instead of calling APIs) that's doable too but you need to pass a session id as cookie instead of Authorization header. That's not an officially supported API though.
What are you trying to do? Can you post any code maybe?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I´m currently designing a mobile application, and I´m having some concerns about securing the backend which runs the services for it to run.
My current planning is, using SSL and a basic workflow like this:
The generated token expires, because it assures that if someone physically access the phone/device, he cant be in control of the user account for too long, but, at the same time, I don't know what duration is appropriated for it, as I don't want to keep asking for credentials every day.
My questions are:
Is this a good aproach? Would you add something else to it?
Whats the ideal duration of tokens when working on mobile apps?
First thing first, you should encrypt session key when you store it on device. For example, use shared preferences with encrypt option. Further info : Android SharedPreference security
Second, you may want to implement "SSL pinning" mechanism. Which means that verify SSL certificates at client side. You must be sure about that received certificate is belongs to your backend or not. So you can protect your backend URLs and parameters with that way. Further info : https://www.infinum.co/the-capsized-eight/articles/securing-mobile-banking-on-android-with-ssl-certificate-pinning or http://www.thoughtcrime.org/blog/authenticity-is-broken-in-ssl-but-your-app-ha/
Third, your design is good. But be sure about your session key generation mechanism is not vulnerability against "Session Prediction" attacks. https://www.owasp.org/index.php/Session_Prediction
This question was previously asked here but the OP never responded to the comment left and therefore it is left unanswered. I'm looking to sign into a specific Box account via API and am hoping there's a way to automatically set the login and password instead of asking users for theirs. I'm coding my app in PHP and so far I'm using the basic OAuth2 process that asks the user to login (/auth/ticket&api_key). So far the only suggestions I've found requires saving files to local storage but that's not an option as I need my app users to do as little work as possible to get in. I just need to tweak this authentication process. Any suggestions??
Thanks!
this is the answer i got from Box API technical support:
Unfortunately, there's no way to do this at this point. You do have to go through the web based login to authenticate, however once you authenticate the first time, you can automate the refresh token so you won't have to do it again. I apologize for that and just let me know if you have anymore questions about this.