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.
Related
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?
I have got an IdentityServer4 project where i protect an API. Inside the Identity Server project i am developing a mini dashboard where i have added some basic administration features like adding clients, scopes, webhooks etc. Also, inside this dashboard, i want to display some information that comes from the API. The problem is that i need not only a cookie (to login to the Identity Server) but also a user token to communicate with the API and fetch the required data. Is this a valid scenario?
I could of course make a separate call, during the initial login, and get a token by using the user's credentials but this does not sound like the best practise, so i want to avoid it at first place.
Also this dashboard could be a completely separate project and use the Hybrid Flow to achieve the desired functionality but i did not want to create a third project for this. Do you believe this is the optimal solution though?
Thank you in advance for your opinions and answers.
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 4 years ago.
Improve this question
we are currently designing an internal REST api. we have the following use case:
a user (109) wants to read a message that he has sent to another user (110)
the reading user (109) is known to the app through his token credentials that he received after authenticating (while doing the GET request)
we assume in this example the user 109 was the sender and 110 the receiver
to summarize from the users perspective "give me the mail that i (109) have sent to 110"
the following URIs came to our mind but we can't decide which one to take:
a) GET http://localhost:9099/api/mails/109?receiverUserId=110
b) GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110
c) GET http://localhost:9099/api/mails?receiverUserId=110
d) GET http://localhost:9099/api/mails/me/to/110 (when logged in as 109 via token credentials we know that "me" is 109)
f) GET http://localhost:9099/api/mails/109/to/110 (explicit request, e.g. for admins … has to be guarded against illegal access)
all the links are "context sensitive" that is sending one of the links to the receiver (110) will yield different results executing the GET request.
i would like to know your opinion on what url to use.
any help highly appreciated.
cheers
marcel
Different responses to different clients, for same URL is okay.
StackExchange does it:
GET /me/comments/{toid}
which is documented here.
Twitter does it too:
GET /statuses/home_timeline
which is documented here.
Both of those URLs infer the logged in user based on authentication. Yes, it defeats caching if users share a cache, but IMO, this is okay. Whether or not this breaks the 'resource identification' constraint of REST is probably debatable. The answer to this question, and a subsequent comment there shows to me why it is debatable.
In fact, among the options, you do mention URLs which are not 'context sensitive':
GET /api/mails?senderUserId=109&receiverUserId=110
This one will always return messages from 109 to 110. But while one client would want to see this result when viewing 'sent' messages, the other would want to see this result when viewing 'received' messages. Kind of weird eh? Plus, on the server you'll have to check that the authenticated user is 109|110, else throw a 401 UNAUTHORIZED.
I would go with something like:
GET /mail/sent
returns all sent mail. And:
GET /mail/sent?to=110 (like applying a 'filter' to /mail/sent)
OR
GET /mail/sent/110 (clean URL)
returns mail sent to 110.
"Context sensitive" links are bad idea for a REST API (in particular, this hinders caching). If you want to just use HTTP this is OK.
So I would suggest using URLs that do not depend on current user and limit access to them according to your rules.
In my opinion, you need 2 layers:
One is the internal layer, which doesn't require user authentication, it's only accessible from internal components. It includes APIs like
GET http://localhost:9099/api/mails?senderUserId=109&receiverUserId=110
The advantage of this layer is the testability, reusability and cachability.
The other layer is the external layer, which requires user authentication and is accessible from external clients. It includes APIs like
GET http://localhost:9099/api/mails?receiverUserId=110.
Clients must login to get the token credentials, then server can get the user info from this token, and map the external API call to internal API call.
You may have different kinds of authentication methods, but the internal layer will not be changed, you just need to map different external layers to the internal layer.
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).