I have created a MVC 4 Web Api using Entity Framework Code-First and a WPF-Application as a client in VS 2012.
The problem I'm struggling with at the moment is that I have to enable Authentication from the client and authorize users for access to the Api (for example: Every authenticated user can access GET methods but only admins can use POST or DELETE). I used MVC 4 Internet Application because of Forms Authentication already being included, which worked fine until I tried to login from my client application. After spending some time researching my problem about I realised that Forms Authentication is mainly supposed to work with webbrowsers. I even found some possible solutions to get it working with HttpClient using CookieContainers (e.g.: How do I set a cookie on HttpClient's HttpRequestMessage), but nothing works for me.
After spending some hours researching ways to accomplish what I'm trying to do I feel completly stuck..
I've read about SimpleMembershipprovider, BasicAuthentication, OAuth and someone mentioned Thinktecture.Identitymodel, but wasn't really able to decide which would work best.
If there is really no way to use Forms Authentication when connecting with a client other than a webbrowser then what is the best Authentication/Authorization method to take?
I would be very happy if anyone could provide me with a hint on what works best in this case, because after researching for hours I only get more and more confused.
Thanks in advance for any help!
You should be able to do this easily enough, but you haven't said what your problem actually is. Are you
unable to get access to your web api actions because you aren't logged in; or
unable to make it enforce authorisation (i.e. you can get anonymous access to actions)
For the second scenario:
There is a very good overview of using Authentication and Authorization in ASP.NET Web API on the server side, and the various ways you can enforce different roles on Actions.
There is also another approach that is appropriate for machine-to-machine (i.e. where you don't have a user who will type their login details into an appliation dialog box) in Making your ASP.NET Web API’s secure, but it doesn't focus on using SimpleMembershipProvider. Instead of using the framework auth&auth components it uses tokens (take care with this approach - rolling your own security is very very hard to get right).
For the first scenario:
From the client side, it sounds like you have some a C# application that user's interact with. If this is the case (rather than the machine-to-machine scenario) then your Forms-based approach is still suitable, and you are doing the right thing with your cookies. The approach would be:
Ask the client to type their username and password in to your application
Send a request to your LogIn action on your AccountsController, this will return your authentication cookie, session cookie etc.
Store the cookies that are returned from this (successful) login (or notify the client if the response was "login failed"
Then use those cookies in the request to the web api
As you are already talking about using HttpClient, I'm guessing you know what you are doing for this, so haven't provided code samples. I wouldn't use HttpClient, for what it's worth, but HttpWebRequest which allows you to keep a common CookieContainer through the HttpWebRequest.CookieContainer property.
Related
I'm building an application in WPF that is client side and will only depend on external API.
To this point I could use open API which I build in RestSharp and everything worked well. But from last week this API uses CAS authentication, so to use them I need to be authenticated. API I want to call is in external server. They have two API's and my assumption is that if I will log in on their site using CAS then I will be able to use this auth for my API calls for second API.
I'm new to SSO, CAS and security overall, so this was my first thought: I will build WebBrowser control, get returned TGC cookie and use ticket from it to use in requests I will be making. But this failed, setting cookie still got me and 401 error and from what I understand from CAS auth for now, TGC is a go to for checking if I'm an authenticated user in current session?
My next thought was to use some CAS c# library. Unfortunately all of advices / libraries focus on creating CAS in .NET projects. Is there some library which will provide a way to log in to CAS auth and then allow me to make API calls?
I hope this makes sense and I didn't messed up things completely. I'm new to secutity and I will be grateful for any help or guidance how to approach this problem. Things I have: API specification (endpoints paths) and username and password to log in to the system.
Is there a way for a native/WPF application to get Identity Server 4 to issue a token without the need for a user interface in the way that Microsoft's MSAL library allows you to - https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Integrated-Windows-Authentication.
The MSAL library only works where you have a Windows user that is backed up in the Azure AD tenant specified by the authority property.
Using the .NET HttpClient class, I was hoping that if I set the UseDefaultCredentials in the HttpClientHandler and setup Identity Server so it uses Windows Authentication as its "provider" that this would be possible.
However when trying it I get a 401 Unauthorized when it tries to authenticate the user at this point in the Quick Start example. I suspect I'm getting Windows Auth problems with the HttpClient class even before we get into Identity Server specifics.
If I got past this stage I would also need to be able to handle the callback to deal with the code/access token. Is there another way to do this?
I realise that a browser window can be shown in WPF to handle everything but for complicated and political reasons within the company we would like to avoid this if possible.
So the proper way to do this is use Auth Code with PKCE, you can configure this to give you a refresh token, so you can argue that you only see the browser once when initially logging in. (I advise this)
If you can't get a refresh token, you can do silent refreshes with headless browser.
If you don't want the browser window you can again have a headless browser and just interact with it via the UI, and simulate the flow without anyone seeing it. (I do not advise this)
If you don't want the browser at all, you can use Resource Owner Password Credentials flow. Please refer to Scott Brady's blog post about weather you should or shouldn't use it.
Many members of the OAuth Working Group now consider the ROPC grant type as deprecated.
And as for
I realise that a browser window can be shown in WPF to handle everything but for complicated and political reasons within the company we would like to avoid this if possible.
Tell them it's impossible to avoid this.
I am creating a .NET class library which will allow local applications to access the accounts of users registered on my website, using an API. I would like the library to handle all authentication of users, so that any app I create an simply call the library, and be returned a token for the API. I'm not sure how to do this authentication.
There are a couple of ways I have considered doing this, however they are not ideal. The first would be to simply create a login form within the library which asks users to enter their login then calls the API. The second method would be to have a webpage where the user logs in and is then given the token which they enter into the app.
The ideal scenario for this situation is that the user does not see their token, and the actual login process is delegated to the website if possible. Both of the above ways lose out on one of those conditions.
The ideal way I would like to do this is inspired from an app I use where if the user is not logged in, they must press a 'Sign In' button, which opens a webpage where they log in. Once they have done so successfully the app automatically detects this and they are signed into the app. The downfall of this solution is that I have no idea how I might do that myself.
Essentially what I'm asking is, is the third solution viable, and how could I do it, or if not are there any better solutions I've overlooked.
FYI the website and API run ASP.NET MVC and WebAPI respectively and the library will use .NET framework.
Edit:
From the comment below it seems likely that you'll want to implement an authentication provider using something like OAuth. The .NET reference libraries can be found here and there's a similar answer already on StackOverflow that may also shed some light.
Welcome to Stack Overflow!
Personally, I would keep the Web API as the authority on authenticating a user and just consume this HTTP endpoint on all platforms (web, desktop, mobile etc) whenever you want to validate a user's credentials.
At a high level the process would be along the lines of:
Have your "clients" (desktop, mobile, web applications) submit HTTP requests to an API route (something like /authenticate) when the user first logs in.
Run your authentication logic
If successful return a token (and cache this this for use in subsequent requests)
Otherwise return a 401 response
Every client will now get a standardised response they can use for determining if they should redirect the user to some protected area, or show them an error message.
This also allows you to design login screens that are native to the platform they're running on (which is a smoother user experience). I wouldn't recommend having a library return a pre-built login page to the user - you'll find that becomes a real pain to maintain!
The third solution you proposed is also a valid way of doing things - but it does have the side effect of redirecting the user's focus away from the application they're using - which you may not want depending on your use case. It's also a bit trickier to implement than just calling the API directly, so unless you have a specific requirement to do it this way I'd not recommend it.
Hopefully this makes some sense. If you are unsure on how to implement cross application authentication then I'd recommend taking a look at some existing answers on Stack Overflow such as:
Basic token checking
OAuth
After hours reading about JWT I am more confused than before starting. Why are jwt being so used if they are not secure within a stateless application? I understand that if a hacker stoles the JWT from a valid user, then that's it, game over.
I am currently starting building an e-commerce with reactjs , and I am struggling with many things. What I want to achieve is two have multiple apis (asp.net web api projects) working (ProductsApi,PaymentsApi, etc..), kind of a reduced version of microservices (without struggling with the communication, api gateway and others things from the beginning ). So, in order to accomplish this I need that a user after putting its username and password, be authorized to use the correct apis. So far I am able to generate jwt that can be validated by all the api projects (https://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/). So, what I understand is that I have two options:
Stateless application: Get the jwt from the authentication server and save on localstorage, so it can be used when accessing the apis. (insecure as hell)
Reactjs inside a Asp.net MVC(Server side rendering): Use cookies (httpcookieonly) to access the apis.
The way I see it, the best approach is #2, so I was planning to still use the jwt thing, BUT adding a claim to it with the sessionid generated by asp.net MVC. Would that make the jwt "secure"? Can it still be stolen and used from another person?
I know I am talking about many things at the same time. It's just I am so confused right now, and I dont find any good post on internet that can suit my needs.
I am creating a .NET app and on one of my screens I have different services to hook up to using OAUTH.
An example of two are Facebook and Instagram. I allow the user to authorize my app access to these applications. Everything is working fine individually however I cannot figure out a good way to know which provider the user selected(I have a simple button click for each service) on callback since both Facebook and Instagram both return "code" on the querystring. Which is then used to do the final step of the OAUTH authorization.
I tried storing the button clicks of each service in session however my session is getting wiped on the redirect to the providers authorization URL and on the return to my app on the callback (and yes even with Redirect(url, false) my session is still getting cleared). So basically I have no clue what button the user clicked with the service the authorization is coming back from (Facebook or Instagram).
Any thought or ideas to know after a user authenticates my app and the callback is made how to know what provider sent me that callback in code behind?
Can't you have them go to different callback URLs? Is there a reason why they need to go to the same URL?
You could include this info in the OAuth 2.0 Authorization Request's state parameter (which you should already use to prevent CSRF attacks), e.g. by appending a _fb or _ig to it.
However, the more convenient way would be to have different callbacks.