I have used the ASP.NET Core React project template to create a web application into which I've installed Identity Server 4. The React app takes care of all the user interaction, with the dotnet application used as an API only. I've integrated a Google OAuth2 authentication option using the services.AddAuthentication().AddGoogle builder extension provided by Microsoft.AspNetCore.Authentication. Finally, the whole thing is containerised and deployed to a Linux App Service on Azure.
Most of my code was ported from a previous version which was a very similar setup but in that case I'd added a custom React app to an existing ASP.NET application rather than start with the official React project template for dotnet. Back then everything worked well. But I'm facing problems with my new version when deployed to Azure. Here's a Fiddler trace to highlight the issue:
vault2 is a client of the identity service. identity-azure is the Identity Server application. The flow this trace shows is as follows:
User clicks Sign In on the Vault application
Browser is redirected to the Identity application
User clicks the Google button to initiate the OAuth2 flow
User signs in with Google account
User is redirected to the default callback URL (https://identity-azure.<domain>.com/signin-google?state=...)
This last step is where the problem is. You'll notice that you don't see the callback URL in the Fiddler trace, but instead you see a couple of other requests (e.g. service-worker.js) which are clearly being made from the React app. So the signin-google path is being handled by the browser's cached React app and not the server. The React app uses react-router-redux to handle certain routes client-side, and of course signin-google is not one of these so it appears to be returning an empty component.
As far as I can tell, all my ASP.NET routes (implemented using the Route attribute to decorate controller action methods) are handled consistently by the server. However, the signin-google route is implemented in the authentication middleware so as far as I know I don't have much control over it other than to change its path. Is there something I can do to force this to be handled server-side?
I should add that this behaviour is quite erratic. It seems that if my Google account is signed out then the above is observed, but if my account is already signed in then signin-google returns the expected 302 status code and the OAuth2 flow continues successfully.
I finally worked out what was going on. At least, I think I have. I can't be certain because I've since broken the React UI out into an entirely separate application but I was observing a similar pattern there. There was even a clue in my original question! Turns out the breaking pages were actually being served from the React app's service worker. I discovered this because even after breaking the React app out under its own domain leaving my identity-azure domain a pure ASP.NET Web API, requests for certain URLs under identity-azure were still behaving the same and I eventually noticed they were reporting themselves as being served by ServiceWorker on my browsers's Network tab. Example below.
As soon as I cleared the browsers application cache (in Chrome on Windows this was F12 > Application > Clear storage > Clear site data with Unregister service workers checked.
I'm not 100% sure what the solution would be if I'd left my React app in the same solution as the ASP.NET backend, but I presume it'd involve excluding specific URLs from service worker. I hope this helps someone in the future.
By the way, if you're thinking of building a fully decoupled UI for Identity Server 4, there's a great starter example here.
Related
We're developing an API and it uses authentication.
During development and debugging I'm constantly starting the api, sending requests with postman etc. But we also use Swagger and I would like to be able to just click on some GetMethods to free up my postman tabs a little.
I know this goes against what authentication is about, but can i set a default user or a default token? I know I can add authentication to swagger and paste in the token, but I would need to do this every time.
I would assume there'd be a simple option to set a default during debugging, but I cant find anything. Is it just not possible?
I also thought about simply not using Authentication when started in debug, but a lot of controller actions need the logged in user.
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
Here's a bit of a back story, feel free to skip to the problem below.
We have a handful of web applications exposed to the outside world (as opposed to ONLY on our internal business network) and these applications are using HTML5 for the offline capabilities. We also had IIS configured for Windows Authentication ONLY (no outside parties use our applications), thus we were issuing the challenge directly against our AD. With a recent update to Chrome for iOS, it broke the NTLM authentication (instead of prompting for use credentials, it just displayed a 401 unauthorized exception page) so we started looking at alternative solutions.
We figured we could leverage our current external ADFS/O365 access thus the user experience would be the same across all external facing applications (not just web apps).
We ended up adding OWIN to our WebForms app to use ADFS authentication and it works from a perspective of you can see the redirect to our external login page and then back to the web app. However, there is an additional problem. To get this to work, we had to DISABLE Windows Authentication in IIS and ENABLE Anonymous Authentication. Also, in the Web.Config in <system.web> we added <authorization><deny users="?" /></authorization>
PROBLEM
Since our applications are using HTML5 and are available offline, we are also using Web API to handle the push of data from the client device to the central system. When we moved to our "SSO type" solution, the POST methods in Web API started crashing. Turns out the line HttpContext.Current.User.Identity.Name stopped working.
How can I get the current authenticated [signed in] user when the user returns to the network and sync's their data? I'm not even sure what the best approach is here, I've tried a few different suggestions from SO and Google, but none seem to work. How does one get the current user in Web API with Owin using Federated Services?
I am investigating how IdentityServer 3 works and I still have problem to fully understand.
In general concept is clear to me but still I am not sure how to implement this on real project.
This is basic example that I am trying to implement in my case: link
I have web api project and I want to call my api methods from any client (mvc, wpf, phone…)
So I need implementation that is suitable for all clients.
If I understand well (and probably I am not understand completely), I should have 3 projects:
Client
Api
Project that host IdentityServer
And all projects should have required stuff like on picture:
Steps on picture:
Get token
Return token
Call api
Check if Token is OK
If Token is fine than return data else show error
My questions are:
Is my thinking about how this works ok?
Where I making mistakes?
Is this example good enough for my case? Am I missing something
important?
Do I have to create project that host IdentityServer, or this is
needed just for example code ?
Does IdentityServer host project must be console application that
communicate with api and client(like in example), or in real world
this is done differently ?
Should project that host identity server be aware of Clients and
Users ?
Should some other project except host identity server project be aware of Clients and Users ?
What is diference between implicit and hybrid flow, what I need in my case and why?
How do I create my own login view? I want have html page for login if I use web client, but to have wpf login view if I use wpf, also different view for mobile client.
EDIT:
I think that I need Resource Owner flow . I supose that resource i view where user type user name and password.
Your basic flow is correct, with Identity Server acting as your authorization server and your client and web API separate.
You should host Identity Server in its own project to ensure it is separate from any other logic which has the potential to introduce security concerns. How you host it is up to you and your use case. Typically you would see it hosted within an ASP.NET project on an IIS Server.
Identity Server must be aware of clients and users in order to authenticate them. The only other projects that should be aware of your identity store (users) is any applications that concern things like admin, user registration, etc. The client store would only ever be used by Identity Server.
Views can be modified using the Identity Server templates or by introducing your own ViewService. See the docs for more info: https://identityserver.github.io/Documentation/docsv2/advanced/customizingViews.html
Regarding flows, the Resource Owner flow is OAuth only, so there will be no authentication (log in page), only authorization (server to server).
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.