We are building a web application that also includes webAPI's. These WebAPIs needs to be exposed to other applications as well (other internal application on different subDomain or 3rd party application). We are thinking of using OpenId Connect, so that not only we will be able to give access_token but also id_token for authentication.
Now the question is 'Should my main application also use openId connect' for authentication/authorization. I am not in favor of this. As per my understanding, only external applications should use openid connect to use main application's resources. And internal applications (main as well as application on different sub-domain) can work with regular cookie based authentication.
For instance, main application is MyWebApp.com (this includes webapi as well). Other internal applications are maps.MyWebApp.com, admin.MyWebApp.com, payroll.MyWebApp.com.
Other 3rd party application could be OtherWebApp.com.
Please suggest.
"Should my main application also use openid connect?"
Advantages
- paves the way for single sign on
- modularizes your authentication so you're not implementing different authentication solutions.
- you have the option of using the same Web api from your main app. (although you could just use the oauth2 client credentials flow and simply skip the openid connect authentication part)
Disadvantages
- if you only had one client app then this could be overkill
- you're adding complexity to the app by making it depend on an authentication server app (but modularizing has advantages too)
I don't know your scenario completely but I'm inclined to say yes. Although, I'd definitely turn off the consent screen from oauth2 for your trusted main app. If you don't use openid connect for authentication, it shouldn't be too hard to convert your main app to use it later
Related
I have two solutions under the same domain. The first one is MVC application with authentication based on IS4 OpenID Connect provider, I'm using code flow. The second one is Angular SPA application with backend on ASP .NET Core ( server just serves static files), authentication here also should be covered by IS4. My question is how can I share authentication state of MVC app with SPA app and vice-versa. Also I can add that it's not necessary to have two separated clients. Authentication can be shared under one client for both applications. Thanks.
Example:
mysite.com/page1 - MVC-client,
mysite.com/page2 - SPA-client
Authentication state will be separate since they use two incompatible technologies:
Client side SPA uses tokens to call APIs
Server side web app uses auth cookies to call a back end
What is common though is the SSO session cookie with Identity server, so after signing on to App 1 you can Single Sign On to App 2 - without a second login for the end user.
This is how separate OAuth apps are meant to behave - the separate redirects mean they can get access tokens with different levels of access to APIs.
This is the simplest solution and any other option could require a lot of re-engineering and has the potential to become a little hacky.
I'm working on building a series of micro-services using Aspnet Core. A mobile application, desktop application and web-application will consume the services over Http REST APIs.
For user auth, I'm utilizing the Aspnet Core Identity platform, but I'm exposing the creation of user accounts via a REST API. The clients make a REST call with the credential information and my API uses the Microsoft Identity APIs to provision the user. The user would be authorized to hit the individual resource servers with an auth server using IdentityServer4.
I have two questions that I've not been able to find clear guidance on from a security stand-point. Should the Aspnet Core project that utilizes Microsoft Identity for user creation be in an independent Aspnet Core project from the project that handles auth via IdentityServer4? Are there downsides do separating the two out that I need to consider?
The Microsoft Identity API has template and Razor Views that can be used to handle the auth from a server-side perspective, including redirects on account creation or sign-in etc. If I'm doing everything via SPA or Client-side native apps, is there anything wrong with just providing a POST API that accepts the user information, creates the account via UserManager<T> and returns the UserId?
I want to provide a dedicated sign-in page, similar to FB/Google/Twitter etc for Auth to happen across any app that wants to authorize a user for my services. I don't typically see account creation as part of the OAuth process though. Is it typical that you would allow for redirects to an account creation page, that redirects back to a client upon successful account creation or is that process typically just used for Auth via OAuth flows?
I would suggest to consider using one service for IDS4 and ASP.NET Identity since they can be integrated and give you the full functionality you're looking for(auth, and users management).
IDS4 has examples and good documentations regarding that.
To me, I think separating them would be an over engineering.
one example: when IDS4 generate access token for a user, you should get claims, roles and validate username and password, all of that are stored in ASP.NET Identity.
So for more details you can check the docs of Identity Server 4: http://docs.identityserver.io/en/latest/quickstarts/0_overview.html
or it's my pleasure to check my little blog post that I tried to give some more detailed and step by step.
https://feras.blog/how-to-use-asp-net-identity-and-identityserver4-in-your-solution/
Start with IDS4 link because it might be enough :)
The main point when thinking about security management UI is how to secure that UI. And the most safe approach for today is cookie-based auth with same-site cookie (the way, MVC uses by default). Consider that when and if selecting serverless SPA pattern. For management purposes-app having strict backend is much more secure than token-based access to distributed api-s.
Regarding the application hosting, #VidmantasBlazevicius is absolutely right, there is no the only strategy: hosting all the services in one app is simpler, so it better fit lo to middle loaded systems. But with raise of the number of users and authentication requests, you might want to scale, and separating management UI from authentication is one of the ways to handle that.
I've been tasked with enabling authentication and authorization for our project's api. The main goal is to protect the methods from misuse, however we also need to enable a developer from another company to call the methods in their code.
Being new to authentication and authorization I'm overwhelmed with the many different options available for .NET etc. Some techniques look promising until you read that they pass credentials in plain text (basic auth?) or have other issues etc... I'm just looking for a reliable and safe approach.
I'm using IIS to host the web api, and I have seen that one such option is to authenticate at the 'host level'. My supervisor has mentioned this is the preferred approach.
I have looked at many threads and videos regarding authenticating in IIS. From what I can work out, such a solution alerts the user that a certain action requires authentication and to enter their credentials.
My issues are as follows:
Given the other developer is not a member of our domain, how can they authenticate using their (windows?) credentials. Is there an alternative to windows authentication?
How will requiring authorization on certain api actions impact the function of the site normally? I.e. will I have to pass valid credentials to the api in my code, for each request?
Overall I'm just a bit uncertain on how this all works and I appreciate any advice given.
I've written a website that requires log in using openauth/openID on top of MVC5, using the instruction http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on
I've found this technique to be very simple and actually enjoyed the process
Now I'd like to add a REST API that is accessed from a C# application running on a remote PC, such that the applications user interacts with an application and not a browser
What is the technique for doing this? Does C# provide an easy way to pop up a browser such that the authentication happens, cookies collected, but then control is given back to the program?
Actually, there are more oauth2 flows and some of them are better suited for different types of applications.
Specifically, there is authorization code grant flow which is for passive clients (browsers) and it involves showing the logon ui from the identity provider.
However, there is the resource owner password flow which basically consist in passing the username and password in the request and getting the auth token right back. This flow is great for desktop/mobile/native apps where you can even have a custom logon ui at the client side.
There are no native libraries, however implementing oauth2 is possible with the DotnetOpenAuth library.
I need to find a way to authenticate/authorize users in a WCF-service. I'm using an external authentication service which stores the credentials of the users.
Eg. "Bob uses our loginmethod, we send the credentials to the authentication service, the service lets us know if these credentials are correct."
If Bob sends another request, we need to know if Bob is already authenticated.
Now a session is being created on the client, but it needs to move to the server-side. We can not rely on clients for security.
Can this be solved by using security cookies or do any of you have a better suggestion?
EDIT! I can only use the authentication server and do not have access to it
The problem you are describing is a well-known one that had (at least) two standardized solutions.
Federation using WS-Trust
The first option is a SOAP based one that uses active federation based on WS-Trust. In this solution:
Your client provides credentials to the authentication service
If the credentials are valid, the authentication service returns a signed (and encrypted) token to the client. It is encrypted so that any information contained in the token remains confidential - even the client cannot read it. It is encrypted with a public key belonging to the your WCF service. It is signed with a private key belonging to the authentication service.
The client submits the signed/encrypted token to your WCF service. The service can decrypt it because it holds the private key for decryption. It can trust it because it is signed by the authentication service.
Based on the content of the decrypted token, the service can establish the client identity and make an authorization decision.
In this model, the usual terminology is:
Your authentication service the Security Token Service
Your WCF service is the Relying Party
your client is the Client
This sounds complex, but it is very well supported in .Net and WCF using Windows Identity Foundation. There are many samples available much of it (maybe all) can be done via WCF configuration rather than code.
This is well suited to scenarios where the clients are crypto-capable (like your .Net clients) and where good frameworks exist (like WIF). It is not so good for low spec clients such as browsers and some phones, or where you are not in control of the clients.
It is commonly used in enterprise scenarios, including enterprise-to-enterprise federation. It is used less often in internet scenarios.
the strengths of it are
It is standardised and therefore generally well supported by frameworks
It means that your WCF service never has to handle the client credentials (= more secure)
It makes it pretty easy to switch to different authentication services (because it is standardised). For example, on-premise AD and Windows Azure AD both support this, as do other independent identity services
An overview can be found here:
http://msdn.microsoft.com/en-us/magazine/ee335707.aspx
And Google will show you lots more walkthroughs and examples.
Federation using OAUth 2
In this solution:
The client displays some UI provided by the authentication service (generally a web page)
The user enters their credentials in that UI and the authentication service authenticates and eventually returns a token to the client. The nature of the token is not standardised, nor is whether it is encrypted. Generally it will be at least signed.
The client submits the token with each request to the WCF service
The WCF service authenticates the token as in the previous solution
In the OAuth terminology:
Your authentication service is the Authorization Server
Your WCF service is the Resource Owner
Your client is the Client
Again, this sounds complex, but it is reasonably well supported in .Net. Probably not as well as the WS-Trust approach though at the moment. It is supported by Windows Azure AD and on the client side, using the Windows Azure Authentication Library. May other services use this approach - e.g. Facebook.
This works well where
Your client is low spec or not crypto-capable (e.g. a browser or some phones)
You do not control the client (e.g. a third party application is accessing your service)
It is very commonly used in internet application where you as an owner of the WCF service don't necessarily know the users or the clients. It is a less complete standard in some ways (e.g. it does not define exactly how the authentication happens) and as a result, it is less easy to switch to alternative authorisation servers.
The strengths of it are:
It is simpler and therefore has wider platform support
It is growing in popularity and therefore the library support is getting better all the time
The user never enters their credentials into your UI, only into the auth server, so it is more likely to be trusted (in internet scenarios)
It has a built in way of controlling the scope of the permissions granted to the client, and revoking those permissions, so again it is more trusted in an internet scenario
The official .Net support for this is in the Windows Azure AD Authentication library
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
There are other, open source components too, such as DotNetOpenAuth
http://dotnetopenauth.net/
Which solution would be best for you depends mainly on the nature of your authentication service I would say. And on whether you are in an enterprise or internet scenario. If the auth. service could be easily adapted to be a WS-Trust Secure Token Service (STS), then that would be a good route. If adding some web UI to the auth. service is feasible, the OAuth might be better.
Or, if neither option is feasible, you could just borrow the patterns form one approach and use that without going for the full standard.
Good luck!