I'm building a Blazor App that uses IdentityServer4 for authentication and authorization to a WebAPI. My goal is to set this up in a way where clients share the same app and api instances but have a separate database. So, all users would see "https://app.domain.com" but they would be presented with data from their database "tenant_1_db", "tenant_2_db", etc...
I've read some stuff on using acrvalues from IdentityServer4 to store the tenant value of the user but not sure if this is the most appropriate way to manage this?
Any feedback would be greatly appreciated :)
Related
I'm creating the user authentication in a web application, and I want to use Identity Server for resource protection.
The sample code and documentation shows how the user logs into Identity Server after creating an account for it. That is to say, they log in with their own Identity Server account. The quickstart even provides a UI.
But I don't want users of my application to have to log in to Identity Server, an external website. I want them to only have to log in to the web application.
So how to proceed? It just doesn't seem at all clear from the documentation how you're supposed to handle this scenario, which I would have thought would be the most common.
Do I just use a pre-defined API scope and user for token validation, holding for all the website's users? That doesn't seem to be very secure given that any user of the website or anyone with the client name and secret would have a valid token. Not sure what the point is in having the security if it's that easily worked around.
Or do I interact with my Identity Server instance somehow after the user is registered in the web application, and store the new user in a database? I can't find any mention of this in the documentation . It all seems to be very muddled to be honest.
Please could anybody shed light on some of this? What is the "standard" approach here? To have the user sign in to the external Identity Server website? That seems a great way to annoy your users.
If you only have one application and you don't intend to add more applications that needs to share users, then you should look at ASP.NET Core Identity
The whole point with OpenID-Connect/IdentityServer is to delegate the managing and handling of users/passwords (authentication) to a central entity. So individual applications don't need to deal with that complexity. IdentityServer is useful when you have multiple applications or if you have more complex integration needs. It is also perfect if you need to customize it to your own needs. If you don't need the customization part you can also outsource it to someone else like Auth0 that give you an IdentityServer like experience as a service.
I am building a reservation system in Google App Engine using Go. I need 2 forms of authentication in my program.
Public Form -- form built in Angular that is on our public website. I want my front-end to have some sort of credentials.json file to use when requesting the book and getOpenDates endpoints in my RESTful API running in Go on Google App Engine.
Private Companion App -- protected by username and password that the user supplies in my app built in Flutter. The app is requesting many endpoints in App Engine. I would like to use JWT to authenticate this portion, but I'm not 100% sure JWT is what I need.
I'm not sure if this tutorial on Identity Platform is what I want. I'm very new to App Engine and authentication in general, so I am a bit lost.
Please describe how I could implement these authentication methods in my RESTful API in Go running on Google's App Engine. I think I may be able to implement the username/password method using a tutorial like this but I'm very lost on the 1st form of authentication with just a credentials file as authentication. If I'm going in the complete wrong direction to accomplish what I want please tell me, but what I'm looking for is code or a tutorial describing how to authenticate using these 2 methods. Thanks for any help.
From what I understand, you want to have a golang backend API in App Engine that serves both your web frontend (1.) and your users app (2.).
I am going to suppose that any user with username/password can use both your frontends: the web app and the mobile app with these credentials.
The credentials.jsons are not designed to authenticate users of your services, but rather server to server communication.
With that in mind, I have found the guide Session based authentication in golang, that could help you to set up your backend to accept only authenticated requests over HTTPS. The web browser will automatically save the cookie, however you need to store the cookie in your mobile app.
For much more complicated scenarios for authenticating from different webpages, it is required to use OAuth2 as you can see in this thread. If you don't find any of your requirements listed in here it is probably overkill to use Auth0 nor OAuth2.
Im searching solution about authentication.
I found IdentityServer and Im trying understand how it works.
In my case I need to check user exist in another app.
I have old project created in asp.net web froms and this project have a users collection stored in db.
Now I must create client who will be call to WebApi and in this WebApi I need to authenticate user. I want to do this using IdentityServer4. Can I in IdentityServer call to my old application or db this application and check user by custom method?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be form new app IdentityServer should check user in his db and if request is from client who will be call to old app should check this user in external app(db).
Example call:
enter image description here
I dont know I good understand idea of IdentityServer, but generaly I think this is not good solution for my case...For now I understand I can store users in database but only with Asp.Identity in IdentityServer.
What do you think about this case ?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be from new app, IdentityServer should check user in his db and if request is from client who will be call to old app, should check this user in external app(db).
The short answer is that IdentityServer4 is just an implementation of the OpenID Connect protocol and the persistence and authentication of users is entirely customisable so you're free to implement that any way you like.
As for where to keep your users - that will depend on your problem domain and business rules but I'd probably try and avoid using multiple DBs if possible and instead migrate existing users from legacy applications to your identity service's own store and take care to only bring over identity and authentication information and not access control/authorization information. i.e. keep the authorization logic in your client applications and APIs.
I'm working on setting up a new SSO application. I would like to use ASP.NET Identity as a database to store the users data. I have a ReactJs application hosted on Node.JS and a .Net Web Api2 application. I want to protect thsi Web Api 2 using Identity Server with users from its database. In further development I'm going to create a mobile application.
I'm able to create an asp.net identity database with some users and use Resource Owner credentials, but I have couple of questions if anyone could help:
Why is Resource Owner Credentials not recommended? My current workflow is to hit the api with client&user&password and obtain a token which I store in web layer and use in Web Api requests. Web Api validates the tokens and identify the user. I read on IS page that's not recommended then what's the recommended scenario to authenticate the user?
How can I create an authenticator for mobile? Should I create my own certificate issue, store it in database as a thumbprint and use access token for that?
Thanks
In short, Resource Owner requires the credentials to be passed through the application itself, also RO doesn't give you SSO. Here's a longer answer. The recommended scenario is to use hybrid flow with PKCE enabled.
Look up TOTP. I believe it is implemented in AspNetCore.Identity with some examples.
I am currently working on a mobile application that will allow a user to sign in via username/password (OAuth 2.0 Password Grant), Facebook, Twitter, or Google. The backend for this mobile application is coded in Spring Boot/Cloud (Java) and makes use of Microservices principles. I have several small services that are discoverable via Eureka and make use of Spring Cloud Config for centralized configuration. They are all exposed to the Mobile device using Spring Cloud Zuul, which acts as a reverse proxy. The Spring Security OAuth 2.0 setup that I have takes in the username and password then returns a JWT token, this token is validated every time a request is made to the backend. I also store users locally in MongoDB and make use of Method Level Security. I want to add Social Login to my application and have it do the following:
On the Mobile Device do the OAuth dance and get an access token
Send the access token to the server, and using Spring Social create a new User locally and associate it to Facebook/Twitter/Google, and then return a JWT token that can be used to validate requests
This JWT token should be created by Spring Security, and I should still be able to use Method Level Security and have local users
Basically I want all the features I have with my custom Spring Security OAuth 2.0 Password Grant with Social Login
This is my first attempt in architecting a system, and therefore am looking forward to responses from those with much more experience than I have. I have seen many examples that use Spring Social, but all of them are for Web Apps, not for Mobile, this is where I am currently stuck at.
The questions I have are the following:
Is my suggested approach adequate? Are there other approaches that are stateless and better for mobile applications?
Is Spring Security OAuth 2.0 and Spring Social Security enough to accomplish this? If so, are there resources that I can use? I have not found many online.
Could Spring Cloud Security be used as a solution?
Should I consider using a 3rd Party provider for Authentication such as Auth0 or OKTA?
using OAuth2 for a stateless solution is in my opionion adequate, because of:
oauth2 in general is a protocol designed to be usable in every client, which is able to perform http requests. Since the social nets you mentioned all support OAuth2. If everything goes bad, you still can consume them manually respecting the oauth2 specs, which they implement.
in general I see a problem with "authenticate with XXX and use that token as JWT for my requests". This is not directly possible, because that token is for their resource servers. Instead you need to separate 2 processes: authentication and authorization. In short you can use the socials endpoints to authenticate a user in your backend, which leads to a second oauth2 generation from your authorization server. This can create a JWT using all features from spring-oauth.
This libary should used in addition, since it helps to setup a application wide security solution. As example, you keep an own authorizationserver (which authenticates using social login) and several resource servers. spring-cloud-security helps to build things on top of that, as Zuul SSO, hystrix+ribbon powered feign clients respecting oauth2 authentications and so on
I don't thing this will help you, because those services primary serve you as an identity provider, while you are going to couple your users identity over social networks
I hope I could clarify your question in some way
I have achieved it by referring two spring example applications. Check this
steps, you will be able to achieve social sso login with Zuul, Auth-server and multiple back-end REST projects.