I've a scenario for a Third Party Client App (Mobile App - With Client Secret) to connect to the Identity Server for getting access to a Resource Server. During the user login the Client App display multiple store location for the user to sign in.
The Client App is designed to have a unique secret for each store location and one Client_ID.
When a store is selected by the end user for login - the ID Server gets a request from the client app with the Client_ID and the specific secret matching to the store location.
The Question I've over here is, how to make the Identity Server (3 or 4) to perform the User Login based on the Store Location.
I'm thinking of intercepting the Client_Secret to use it during the User Login to map to the correct store id by having a lookup table in place.
Is this a good approach to get this scenario worked out, or can someone shed some light with any possible suggestions to make this scenario work with the Identity Server.
The Expected flow:
Client App Displays the Store Location's in the Login Screen
User Selects the specific store location
User is directed to the Identity Server Authorization Endpoint and Client Validation is taken place.
Authorization Server Displays - User Login Screen
The Authorization Server authenticates the end User based on the store location. (Need to figure out a way to achieve this)
If you intend the login flow to be completed within mobile app itself and not within browser client, then you will need to use resource owner credentials grant type, in which case, it doesn't really matter if you have one or many secrets per store as it authenticates a single client based on your scenario.
On the other hand, if you intend the login flow to be completed within browser client, then it also doesn't matter if you have many secrets or one because in that case I assume the store selection would be done within the login screen like you mentioned which would part of the auth server.
All in all, nowhere in your flow the store location seem to matter unless there is some kind linkage between user credentials and store id. If that is the case, then this is essentially a multitenancy question for Identity Server 4 for which there are discussions already open with suggestions.
https://github.com/IdentityServer/IdentityServer4/issues/2673
How should you secure a multi-tenant API with Identity Server?
Related
I am creating an electron application that connects to an Database and do POST and GET requests to retrieve and insert data into it, the problem is that in the code i have defined my database uri ( im using mongodb)
const uri = "mongodb+srv://<myusesrname>:<mypassword>#cluster0.wqbiu.mongodb.net/query?retryWrites=true&w=majority"
like in the example above, but if i pack my electron app the connection to the database as well as the credentials its visible if someone unpacks the app.asar file and look in the server.js file how i can solve this problem? i dont want any security breaches neither for me or the people that will be using my application, thanks in advance for any answer :)
An application that requires a secure connection to something cannot afford to have any username's or password's hardcoded into its code.
Instead, a procedure of authentication and authorisation is utilised.
Authentication is used to verify the user. IE: They are who they say they are, often achieved via the use of some type of login form.
Authorisation is used to verify the logged-in user is allowed to access the requested resource. EG: Is this user allowed to retrieve a list of all users email addresses from the database.
As a rough guide, a user will login with their username and password. You could use OpenID as well here if you wanted. Once the user is 'logged-in' you could set a cookie or session and save the session id in the DB against the user. Of course, all of this is done over HTTPS.
There are various ways to control the validity of the session such as but not limited to refreshing the expiration date / time every time the user hits the server, auto timeout if the user has not interacted with the server for more than X minutes, etc.
In your app, the user could try and interact with the database at any time, but if the user is not logged in, the server could return the appropriate response and prompt the user to login. Some form of API here is really the way to go.
If the user is logged in then then next step is to authorise the users request, ensuring they are allowed to perform what they are asking before sending a response back. If they are not authorised to access the resource (EG: Edit another user’s post) then an appropriate response is returned indicating so.
As you can see, securing your app will take some work but the result of not doing so could be devastating to you and your users.
I'm having the most bizarre problem, which I thought would be quite simple to fix. I helped a client set up a connection to the Amazon Selling Partner API by creating a private app in Seller Central:
Settings > User Permissions > Visit Developer Credentials
New app client
Get LWA credentials (client secret and client id)
Self authorize the app to obtain a refresh token
I've been using this successfully to pull Amazon SP API data for this client, but now the client wants to ensure we don't keep having access to their data and would like to either remove the app and create a new one or at least invalidate existing refresh tokens and/or client secrets and generate new ones. It's quite easy to create a new refresh token, but this doesn't invalidate the existing ones.
I've tried everything, including unticking all the boxes that grant you access to various scopes and putting in a random IAM ARN, but you have to leave at least one box ticked and the ARN has to match an existing one. Getting a non-technical client to create a new IAM ARN just for this doesn't make us look great, and I'm sure there has to be a way to revoke those credentials - what would happen if they became compromised for some reason?
I am trying to access the multiple communities in multiple salesforce sites with same connected-app but could not.
For example: I have created the two salesforce sites A and B. And created connected-app in A. To access rest API of A, i could authenticate with connected-app in A, But how to connect with B with using the same client_secret and client_id by differs in user_name and password?
Or is there any way to connect with REST API with username and password as creds?
Example: There is community_A1, community_A2 in Site A and community_B1 , community_B2 in Site B.
I need to access communities in both the Sites
This should work out of the box, what errors you're getting?
You can have 1 set of consumer key and secret and (if admin in target org didn't block it) you could use this to login to any SF in the world, sandbox or production, core SF or community.
Imagine being a developer of mobile app that pulls data from salesforce. You'd want to have just 1 pair of keys, not install separate key for every org people might install your app...
All org-specific stuff you need is username, password and login url. For community the login url will look like https://sandboxName-MyDomain.cs123.force.com/communityName
Once you have that, you can inspect all the OAuth2 stuff at https://sandboxName-MyDomain.cs123.force.com/communityName/.well-known/openid-configuration
Have you played with https://openidconnect.herokuapp.com/ ?
Paste your community url, for now keep the client and secret as is, click next. Login to community and keep clicking next. It should work fine and at the end - give you access_token / session id.
Now close this browser completely / open new incognito window and do it again. This time give your login url but also client and secret. Next, Next... Check the user's login history, it should mention your connected app now.
Now close this and do it last time, with the other community's login url and another user's credentials but still with your client and secret.
is there any way to connect with REST API with username and password
as creds?
Not for community. Internal users can get access in one go with https://help.salesforce.com/s/articleView?id=sf.remoteaccess_oauth_username_password_flow.htm&type=5 but community/experience users need this interactive login, there has to be a human consent / password typing step. And anyway it's not very secure flow. "Experience Cloud sites don’t support the OAuth 2.0 username-password flow."
In a pinch you could try the SOAP API's login method but from what I remember you may need to pass the community's Id in the message then
Connected-app is global metadata in salesforce. Once we create a connected-app in one org, then can access any salesforce site with the same client_id,client_secret, unless the admin has blocked the access.
I needed to add the custom profile into the community members to allow the access to the community via API (Community workspace -> administration -> members -> profiles.)
With IdentityServer4 I need to allow a single user session per time. If the user authenticates with device A and then with B, session and access token must be invalidated for A and, even better, client A could receive a notification that user has logged out in a second step.The main thing is making the server force invalidate session and token. There are similar questions, one of them redirects us to the following link:
https://github.com/IdentityServer/IdentityServer4/issues/736
where it is explained to use backchannel logout and in the login method of the identity server to obtain the previous IdentityServer sessionID that should have been persisted somewhere. Then I should send logout tokens to all clients.
Another solution is given here
How to Logout user from a particular session Identity Server 4, .Net Core?
telling us to use an ITicketStore implementation to be able to invalidate the session.
The configuration used is IdentityServer4 with authorizaton code flow with PKCE. Which approach is best for my case? Is there another approach where I could simply delete the access token in the id server database?
I think in your case probably a combination of both. In our real-world implementation we combine server-side storage of sessions via ITicketStore (stored in a custom database with sessions linked to user accounts and also storing the list of client IDs for each session) with the ability to trigger back-channel logout of any session at any time (i.e. not just via the default user-triggered mechanism).
In our case we do this to be able to invalidate sessions for other reasons (e.g. password or other security setting changes, a "log me out of everything" feature, impersonation rights being revoked etc) but this approach could form the foundation of a "single session per user" feature should you wish.
I have identity server 4 setup and my asp net core app working with it. If you hit a secure endpoint it redirects to Identity Server and you can login. Once you login it then redirects back to the url you were originally trying to access. What I would like to do is check that you have registered in my database before you get redirected. I thought that I could change 'RedirectUris' to a url of my choice but when I do that it has no effect. A breakpoint on that end point is never hit. What do I need to do in order to setup a post identity server login registration screen?
Is this the right way of doing it?
Thanks
Michael
If I understand your problem correctly, you want to get the user details in your application.
IdentityToken contains user name if you include Name scope.
If it is a web application then you may find the name on ((System.Security.Claims.ClaimsIdentity)User.Identity)
You can also add claims as you need, like userid, role etc
Comment
should each client have to 'register' a user with my api specifically?
What's the norm?
Depends on your requirements and what you are requesting for. On my case user must have allowed scope to access the api