I am trying to resolve the following problem using best practices.
We have an API server, which uses Authorization with JWT token to call our api endpoints. Now we need to develop Multi platform application (Android, iOS, Web) to consume this api.
We are planning to use .net MAUI for Mobile and Blazor for Web application. All these applications will have a common user base.
Also we would like to share api to third parties, and we would like also to put their users in our common user base.
What would be the proper approach to do it ? Should we add Identity server to our Web API project ? Should we create separate Identity Server project which will share userbase ?
I would recommend to use IdentityServer and also do host it in a separate service is a best practice.
Because otherwise it will be harder to debug and troubleshoot when you mix IdentityServer with other services.
Related
I am developing a solution using .NET ASP Core. It's current version is monolithic, and I want to switch it to a service architecture consisting of an HTTP API which is used by the iOS/Android apps and web site. Here is a visual:
I am using .NET ASP Core on the website and service layers. I have almost finished implementing the changes, but I'm hung up on how to handle authentication on the area of the website that allows administrators to edit the content of the system. The monolithic version uses Identity Core (custom implementation, not using Entity) which works great. I could move the identity authentication code into the service, but I'm not sure how to then handle the authentication on the web site (the apps are public content only, no auth needed). How do I pass the username/password from the website to the service? How do I then track the session between the end user and service layer? Or is another option like OAUTH make more sense? I'd prefer a solution that doesn't require me to implement duplicate roles/policies on the website and service.
Any suggestions welcome, I have no experience with a setup like this so I'm not really even sure where to begin. Thanks!
OpenID Connect or OAuth makes sense because all of the claims/roles you already have will be encapsulated into the token. I presently use IdentityServer4 and it works just fine for your exact situation.
Since you are already using Identity database implementation doesn't matter as long as you have a back end. In the end the calls to the site are till http in nature, all very well documented.
http://www.identityserver.io
We are starting a project which will consist in:
Web project (ASP.NET MVC)
IOS app
and both will consume data from a .NET WEB API service.
The WEB API service will expose a POST Method with the url "user/create". But i don't know how can i avoid another apps for making post to this url? I know i need a security protocol, but i wanted to know which one you recommend me, and if you have, an article where is it explained.
Thanks
web api 2 provides oauth authentication. You will need to get a token from the token end point of web api and pass that token in subsequent requests.
You should find lot of online resources if you search for web api 2 oauth.
We did something similar recently using OWIN OAuth 2.0 Authorization Server
Reference this ASP.NET page for details. Sample code is included as well for several different implementations.
For our purposes, we used the Client Credentials Grant section about half-way down the page. Our implementation involved server-server OAuth (Web API to MVC), but I bet it's pretty similar to have iOS connect. The only thing I would caution is to somehow encrypt the login credentials on the iOS side, and I'm sure there is a way to do that.
So you want the WebAPI to only be used by the MVC page? The best architectural method is to separate the two rather than leave both in one project. Why? Because the MVC app is a experience layer for humans. The WebAPI is an experience layer for the MVC app. Move it back where it can't be accessed.
You can add on tokens, etc, but the MVC app sits on the server, but is accessed on the client computer. The wider the scope of the application (ie, intranet or internet or something in between?), the more difficult the problem and the harder it is for your users to access the application. Moving the WebAPI internal and leaving the MVC app exposed guarantees external users cannot use the API.
The main reason WebAPI and MVC exist together in a single project (still a mistake in most instances, IMO) is you are exposing both to the same audience. If that is not your intent, don't do it.
I have a WPF client application and AngularJs client connecting to the same Web API to get\send data.
I want to apply OAuth with Azure as identity provider.
What I want is to use this single Web API that both of the applications calling, not to create separate APIs for each.
Thanks
I found a solution,
When you want to authenticate SPA app & WPF and both of them using the same WebAPI you'll face a problem, that in SPA case (see this sample), in the server side (WebAPI) in the Startup.ConfigureAuth you need to set Audience property same as ClientId, but when you need to apply OAuth with WPF (native client, see this sample) you'll need to provide it as "App ID URI".
You solve this by adding the code from the first sample and the code from the second both in your Startup.ConfigureAuth method in your project.
I am hoping someone can clear up how these things can work together.
I want to be my own identity provider, so in my web api I have an OAuth token provider. I want users to register with me and then be authenticated using my token provider. The idea in the future is that more of my mobile apps and web apps will be accessible using the OAuth login sharing the user's identity.
So, if I use azure mobile services how do I implement the normal asp.net identity stuff?
And, how would a normal web app be able to use the data stored in azure mobile services? Would I have two dbcontexts one for mobile and one for web?
I've been reading and watching a lot of stuff on azure but nothing seems to show how I can do this. Most of it has to do with using external providers like facebook, ms, twitter, etc. I want to be one of those external providers, just not sure how to do it and allow my websites to still use the .net identity data.
If you could point me to or post some example / tutorial / blogs that would be great.
This is a supported scenario, although it isn't documented very well at the moment.
The Mobile Services .NET runtime is built on the ASP.NET Katana authentication middleware. The mobile service abstracts these middleware using the LoginProvider base class. The authentication model was recently made extensible for situations such as yours. In order to have Mobile Services recognize and use your identity provider, you would have to create your own LoginProvider.
There are currently two examples of this:
Adding a Katana middleware as an identity provider - part of this post.
Creating a custom username/password setup - tutorial here.
You could certainly use these techniques to wrap the standard ASP.NET identity functionality.
As to your question about accessing the data, there are a variety of approaches. Your web app could treat Mobile Services as a backend and pass through requests. This is basically treating the web app as an additional client platform, peer to your mobile apps. Another option is to, as you said, create multiple DBContexts. While you might get slightly better performance, this comes with a code maintainability tradeoff. It also wouldn't scale well if you build multiple web apps on the same data backend.
I've created an application that is comprised of three main components:
A .NET Web Api 2 project that provides several WebApiControllers. Some methods, like "Register" are open to anonymous access, while others are authorized using token-based Basic Authorization (the standard .Net Identity 2 approach included in the .Net WebApi2 templates). In the interest of quick-and-dirty functionality, this layer communicates directly with my database using Entity Framework.
An MVC5 project that provides a front-end web client and communicates with the Web API.
An iOS client that communicates with the Web API.
With this structure, end-users ("consumers") can create their own accounts using the unauthenticated "Register" API method. Users can then access and manipulate their own data via authenticated methods protected by token-based authorization headers.
Here's my question:
How do I prevent unknown clients from making calls to the API, without creating significant overhead or overhauling the standard .Net Web API authorization functionality?
Ideally, I'd like to be able to have some sort of table of identifiers for client applications so that I can allow new client applications or disallow them as necessary.
Take a look at the knownClientApplications parameter in the Active Directory manifest.
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-application-manifest