I'm using ASP.NET Identity token authentication in several separate OWIN Web Api 2 services and want to consolidate the services to a single server. Each currently has their own /token end point. My vision is to have a single /token end point for all of them, but this means sharing auth tokens.
In ASP.NET Forms Authentication, the auth cookie could be shared by using the same machine key value in any application that participated in the sharing, so I'm thinkng it a similar mechanism.
Is this possible? If so, how?
Related
I've got a SPA application which gives statistics and information to anonymous users. It is a react spa app and will consume backend REST Web API(.net core). These data are not specific to users, therefore the information is freely available and no user authentication is required. However, I don't want my Backend Api layer to be exposed to the internet (i.e not use by anonymous applications such as postman, rest clients, etc). I'm familiar with the Client credential flow (OAuth) but I can't use it for this application because there is no concept for user login in this application.
What would be my best options that limit access to my API layer to anonymous applications (i.e postman, etc), or is it not possible at all?
You can't use client credentials flow for your SPA. Anyone would be able to download your SPA, extract the client id and secret and use it to call your API.
If you do not want to authenticate your users, there's no good way to protect your API. Move your SPA to a traditional web application hosted on a server to protect it using client credentials flow.
It's not possible to make an API accessible to a public client (your SPA) without also making it accessible to users making API calls from Postman or custom code. It's possible to do the reverse, only because of the limitations that browsers put in place.
Depending on what you're trying to achieve, you could use something like reCAPTCHA to validate that the users of your API are humans, not scripts. That along with human-scale rate limiting would probably filter out most of non-app users.
I have a DashboardApi and an EnterpriseApi on my system. May be one more later.
I am new at IdentityServer3 and I wonder solve my problem.
IdentityServer saves client applications that will use an api. So I have 2 or 3 api. Will I create IdentityServer for all api? Because DashboardApi will consume EnterpriseApi. EnterpriseApi will consume another api.
And users will login to Dashboard application. I could not imagine the organisation.
To answer the question: you may have one instance of IdentityServer being your identity provider/authority across different "resource" APIs as long as they all point back to that same authority when it comes to token validation.
Then an access token used for "DashboardApi" can be used by "EnterpriseApi". It is important to proxy the token properly and in my experience it would be advantageous to create different scopes for each API to have better access as to which calls may be used to proxy into the second API through the first (especially if user consent is a concern).
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.
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 am putting a plan together for a series of sites that will share user account information among them. The idea is that once a user logs in using their OpenID, they can access any of the sites and it will know who they are.
What are the common patterns/best practices that i could employ to achieve this?
If all the sites share a common hostname in their URL then you can set an auth cookie (FormsAuthentication.SetAuthCookie) specifying the path of the cookie to be "/" so that all sites can see the user is logged in.
If the sites are not sharing a common host name, I think the only way to get a truly "once signed in, signed in everywhere [within your ring of web sites]" would be for all authentication to happen at just one site (perhaps one dedicated to authenticating the user) and for the other sites to redirect the user to that site for authentication and then that site would redirect back. In essence, that auth site becomes an identity provider, and almost exactly fills the role of an OpenID Provider (in fact DotNetOpenAuth could be used here for this exact purpose). Since it sounds like your goal is to let the user log in with their OpenID, your OpenID Provider on that one auth site could itself use OpenID to authenticate the user. Your own pure-delegation OpenID Provider could be written such that it always responds immediately to checkid_immediate requests as long as the Realm in the auth request is one of your trusted ring of sites. Thus you could effect single-sign-on across all your sites.
Please consider the following Patterns & Practices on Web Service Security from Microsoft:
Brokered Authentication - http://msdn.microsoft.com/en-us/library/aa480560.aspx
The main topic is - Web Service Security
Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
http://msdn.microsoft.com/en-us/library/aa480545.aspx
Ultimately theres lots of ways you could do it. I achieved a simple single sign on by building a url with a token from one website pointing to another domain. The encoded & encrypted token contained details to submit back to the previous domain. Upon receiving an incoming request on the second domain, an underlying web service checks that the incoming request's token is valid with the previous domain using a shared private secret, known to both domains.