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.
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.
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
I need to implement authentication for some web services that we will be hosting. I want to use open standards, so I am interested in OAuth.
I will be using WebAPI for these services.
So here's where I'm running into trouble: Most (or maybe all) of the Api Key/OAuth scenerios that I have read involve (at some point or another) a user sitting in front of a screen.
I need to put together an API that a business partner will be calling. The calls will come from an automated process -- nowhere in the chain will there be a person who can be redirected to a web site with logon credentials.
However, I don't want just anyone coming around and calling my services.
So, I read about OAuth, and how it uses a shared secret to sign each request, and I think that's what I'm after. (I would either set up a session key, or could consider making one of the parameters a "ticks" value, and only accept requests within a short timeframe, etc)
I was kind of hoping that I could use DotNetOpenAuth to accomplish this (or something like it), but every example I come across begins with "the user gets redirected to a login page). I only need "2 leg" authentication.
Is there an example of using DotNetOpenAuth to do this?
Is there a better way to go?
If you are looking at OAuth 2 then the flow you are describing is the Client Credentials Grant
This kind of "two legged" / "service account" type flow is one that doesn't have a web page based flow.
DotNetOpenAuth supports the Client Credentials Grant. You can see an example of it in action here; however, be aware even though the author states it is the "Resource Owner Password Credentials" grant it is actually the Client Credentials Grant.
The blog post above was a little out of step with the latest DotNetOpenAuth code base but these are quickly identified and altered.
I believe that as it stands the DotNetOpenAuth only supports issuing a Bearer token using Http Basic authentication. There are other more exotic extensions OAuth 2 with a similar flow e.g. the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants (but as stated this is not yet part of DotNetOpenAuth).
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.
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.