I currently have the ability to host one and only one site (meaning under one domain). I will have a SPA front-end, Web Api resource, and then IdentityServer4 for security (utilizing AspNetCore Identity framework for user management).
Something feels "wrong" with this approach as a single hosted site architecture. I believe AspNet Identity creates an auth cookie once authenticated, and then IdentityServer would be serving up JWT tokens for my SPA to call my API.
Upon further reflection though, this seems misguided. The thing that seems off is that I believe my API calls will also have the auth cookie automatically attached along with the JWT token in the header because the API call will be requesting from the same domain as the auth cookie was generated. And so it seems I'm using two forms of authentication at once unnecessarily... thoughts?
In other words, when everything is running under one domain, is adding IdentityServer4 to an AspNetCore Identity-enabled application unnecessary? The one benefit to plumbing in IdentityServer4 would be to future proof the application if it were to ever be deployed separate from its Resource (Web Api), then you would have nothing but configuration to modify.
Related
I've got 2 different .NET Core 2.2 MVC projects. I'm using IdentityServer4 for the token server, Azure B2C for the identity store.
The 1st MVC app is a normal MVC application, and I've got it working perfectly with the OIDC Hybrid flow.
The 2nd MVC app is an Angular 7 cli app, which serves up the index.html and houses the API that the app will be calling. The angular app will not call any other APIs directly (gateway pattern).
My questions are about the 2nd app - I'm trying to figure out the best way to set up the Angular app for security.
My understanding is: OIDC Implicit flow exposes exposes the access token on the browser. OIDC Hybrid flow does not expose the access token (at least when hitting the same web server - no CORS), because the web server (client) uses the back channel to obtain the access token, via the authorization code, and its never exposed to the browser.
QUESTION #1: Is my understanding of Implicit vs. Hybrid correct?
If my understanding is correct, I'd think the best way to go would be Hybrid flow even for the Angular app, but most samples I've seen for using OIDC with Angular involve the Implicit flow, and don't take advantage of the authorization code / backchannel. Avoiding having an access token on the browser seems like a big deal, like a worthy goal, but wondering why it doesn't seem to be done?
QUESTION #2: I'm serving up my Angular index.html from my MVC server - why can't I just use Hybrid flow to protect the index.html page, and keep the token on the backchannel?
Something tells me my understanding of all this isn't quite complete...
Your understanding is correct. You can protect your index.html. The only problem you will face that way is that it's not the default configuration for today. With your requirements, most likely you don't need any of oidc client libs at all, you can protect your (only) API with a (same-site, http-only) cookie (not a bearer token) and in your Angular guards just ensure that you are still logged in to your back (if not, redirect through a local MVC resource to involve server-side code into login procedure).
See this question, especially the comments and link below for further reference.
The case: the System-K has many microservices. One of them is the OAuth microservice which provides access tokens for 3rd parties that will consume some data managed by others microservices of the System-K.
The System-K also have a frontend that is a SPA web application. This SPA also consumes the same data that 3rd parties do, but with the difference that this SPA will be able to query privileged data since is the owned Sysmte-k front-end.
The question: Which OAuth strategy to use for the SPA? or I should use another approach to handle authentication request made by the SPA and leaves the OAuth server just for 3rd parties?
Under the hood:
The web application is built with Angular 7+, this sends requests to an APIGateway which is a microservice, part of the Sysmte-k, then APIGateway routes such requests to the target microservice.
3rd parties OAuth request are sent also to APIGateway which routes to the OAuth microservice. All microservices are build in Node and written with TypeScript.
Update 1
I do not want users who authenticate in the SPA to see a screen saying "Do you allow the System-K to access your Sysmte-k profile?" since the SPA is the System-k client itself.
Question: - Which OAuth strategy to use for the SPA? or I should use
another approach to handle authentication request made by the SPA and
leaves the OAuth server just for 3rd parties?
Unless your SPA has a backend server (which means that your SPA is not really an SPA) you are limited to using implicit OAuth. Implicit OAuth runs in JavaScript in the browser.
For implicit OAuth I strongly recommend using a third party Identity Provider (Google, Auth0, Okta). Getting the security correct in your own code is very difficult.
If you can add a backend service to provide three-legged OAuth, your security will improve and you will have many more options. Again I recommend a third party Identity Provider.
I believe the short answer to my question is "No", but allow me to describe the context.
We are currently using IdentityServer to authorize access to our APIs (via client credentials). All of the API clients are computer programs which run in our data centers and are under our control. In order to minimize our attack surface, our IdentityServer is running from an internal/private network, reachable from our APIs, services, and other apps. No problems.
We now want to leverage the IdentityServer installation to provide user authentication for our public-facing web applications. These applications run via ASP.NET MVC and will consequently require user interaction with the IdentityServer for password validation (implicit or hybrid grant type). This appears to be a hard requirement, but I'm curious if there is a simple way to maintain the private installation of IdentityServer.
Can we proxy requests from the ASP.NET middle-ware for handling the authentication handshake, and does it even make sense to do so? I'm leaning towards a public-facing STS to eliminate any proxying, but thought I would ask to see what other patterns are employable.
For what its worth, we would ultimately use cookie-based authentication with the hybrid flow, but would be able to start with the implicit flow too.
The user's browser must be able to access the identity server. This can be via a proxy though.
the below process which i have followed while implementing single sign on
Decoupled Authorization server & Resource server
Got access-token using client_credentials from Authorization server
Problem:
i have used mvc 4 application for resource server and can't able to access views(resource) from resource server using mvc controllers with Authorize Attribute
used access-token generated by authorization server
also read the below question:
"I have an un-secured MVC 5/Web API 2 application. It accesses resources using a combination of MVC controllers, and ajax calls to the Web API endpoints.
Eventually I would like to move all resource access into a separate Resource Server. However, for the time being, I would like to get the application into production as a proof of concept for a line of business applications secured using the OAuth 2 framework.
I have configured users in IdentityServer, and added the application to AuthorizationServer using a code flow client. Based on the sample provided with the AS code, I am able to retrieve an access token in the application, add it to the request headers for Web API endpoint calls secured with the Scope attribute.
My questions is how can I utilize this same flow to secure the MVC controllers? I imagine it would entail setting up an OWIN middleware component which will set the authorization headers for each request based on a cookie which contains the token. Am I on the right path, or should I go in a different direction with this?"
please let me know how to access the mvc resource using owin middleware instead of web api.
I'm re-developing an app as a web app (the "previous" iteration was in VB6) to run on azure. One requirement is that we only use facebook/google authentication (OAuth 2.0). Another business requirement lead me to break my project into the following schema:
1 Project for the WebAPI 2.0
1 Project for Controllers
1 for Data Access (typical layer pattern)
N Projects for MVC 5 front-end
The idea is that the MVC projects will only consume the WebAPI via javascript/json! The N MVC projects will contain just the GET implementation for the pages. No models or others actions (post for example). In other words the MVC projects are completally disconnectd from the other projects and should have no intelligence what-so-ever!
This is the selected way because of (bitchy clients and) limited time constraints.
Anyway, as you can notice the "core" (WebAPI + controllers + DA) is shared. The core is in fact a multi-tenant service. (but remember the disconnected facet!)
My problem here is: How do I handle Authorization? What/how should treat the passing of the claims between the MVC projects and the WebAPI? Im lost here. After some thought, I came to the conclusion that I need to make the WebAPI project act as a proxy here, something like:
Random users lands on www.myClientWebsite.com/Register
Chooses a login provider
The MVC project redirects the user signaling facebook to return to www.myWebAPI.com/Register
I intercept the claim and redirect the user to the original www.myClientWebsite.com/LoginComplete or something...
Am I getting it wrong?
You have to use OAuth 2 for authentication and authorization purpose in this scenario. Yes, you should be making the authentication at the MVC level and then use tokens to keep the security intact for rest calls.
Here your MVC application should get a Bearer token from the identity provider like google and then hide it some where on the form. Then for every jquery request you make to web api, you have to send this bearer token in the request.
[Update]
This is considered kind of hack and I do not encourage it. And this works only if both the systems are in same domain.
[\Update]
If both MVC and Web API are on different domains, then you can think of using Azure ACS Service Identity to build the trust between domains. Then pass the bearer token of User claims in the payload of the request.
[Update]
This is much more better way to handle this but must be accompanied with proper token revocation and https security.
[\Update]