I am working on combination of Web API application and desktop client program (WPF). I am using Microsoft.AspNet.WebApi.Client for a client-server HTTP communication and now I want to use authorization / authentication system of the server application to authorize user of the client program.
Point is, I want to use (=start with) the same HttpClient class, I would like to use ASP.NET Identity library on server side - call controller with credentials in HTTP header, receive actual token from server, keep it and than use it for authentication in other controllers where it is required.
I know the theory, some basic steps, but I have not found any useful and actual resource with a simple examples or tutorial how to do it well. Does anyone know about good resource to learn, how to do that?
Thanks a lot.
Related
Let's say I have an installed app, a console app for example, not a web app, that I want to interact with the QBO API - I want to perform calls to QBO from my console app (but not from a web application). So I must authenticate from the console app, make a call and output in the console.
All QBO SDKs seem to ask for a callback URL or a redirect URL, i.e. a page on my server, that will perform the required leg of the OAuth 2.0 authentication. As my installed app is not a webserver, I don't have a place to host this logic. Yes, I can host a webserver to handle this logic, but I don't want to do it, this is a waste of resources for my use case (why leave an auth server on standby?). I just want to authenticate without a webserver with QBO API. Is this possible? Have I messed up my understanding of the API or of OAuth? I am at a total loss. In none of the sample code I can find a suitable example despite this being the use case that I have. (I am working with .NET / C#)
It appears that at the moment the QuickBooks Developer platform will not accommodate this (non web End-Point).
As per Intuit:
These URIs handle responses from the OAuth 2.0 server and are called
after the user authorizes the connection. URIs in this list are the
only ones to which the authorization response can be sent from the
OAuth 2.0 server. You must define at least one URI specifically for
your application's auth endpoint before you can use OAuth 2.0.
Additionally they add in a note:
Mobile- or desktop-based apps that implement OAuth 2.0 must provide a
separate SaaS layer for the Redirect URI to handle responses from the
OAuth 2.0 server.
I realize this is not what you had hoped for. Please understand, however, understand that the end-point must be a URL so as to securely return the authentication token.
We are starting a project which will consist in:
Web project (ASP.NET MVC)
IOS app
and both will consume data from a .NET WEB API service.
The WEB API service will expose a POST Method with the url "user/create". But i don't know how can i avoid another apps for making post to this url? I know i need a security protocol, but i wanted to know which one you recommend me, and if you have, an article where is it explained.
Thanks
web api 2 provides oauth authentication. You will need to get a token from the token end point of web api and pass that token in subsequent requests.
You should find lot of online resources if you search for web api 2 oauth.
We did something similar recently using OWIN OAuth 2.0 Authorization Server
Reference this ASP.NET page for details. Sample code is included as well for several different implementations.
For our purposes, we used the Client Credentials Grant section about half-way down the page. Our implementation involved server-server OAuth (Web API to MVC), but I bet it's pretty similar to have iOS connect. The only thing I would caution is to somehow encrypt the login credentials on the iOS side, and I'm sure there is a way to do that.
So you want the WebAPI to only be used by the MVC page? The best architectural method is to separate the two rather than leave both in one project. Why? Because the MVC app is a experience layer for humans. The WebAPI is an experience layer for the MVC app. Move it back where it can't be accessed.
You can add on tokens, etc, but the MVC app sits on the server, but is accessed on the client computer. The wider the scope of the application (ie, intranet or internet or something in between?), the more difficult the problem and the harder it is for your users to access the application. Moving the WebAPI internal and leaving the MVC app exposed guarantees external users cannot use the API.
The main reason WebAPI and MVC exist together in a single project (still a mistake in most instances, IMO) is you are exposing both to the same audience. If that is not your intent, don't do it.
I have a WPF client application and AngularJs client connecting to the same Web API to get\send data.
I want to apply OAuth with Azure as identity provider.
What I want is to use this single Web API that both of the applications calling, not to create separate APIs for each.
Thanks
I found a solution,
When you want to authenticate SPA app & WPF and both of them using the same WebAPI you'll face a problem, that in SPA case (see this sample), in the server side (WebAPI) in the Startup.ConfigureAuth you need to set Audience property same as ClientId, but when you need to apply OAuth with WPF (native client, see this sample) you'll need to provide it as "App ID URI".
You solve this by adding the code from the first sample and the code from the second both in your Startup.ConfigureAuth method in your project.
I am aware this is the most basic question and is asked many times, however I have failed to find relevant details for my requirement.
I am developing ASP.Net as front end and using ASP.Net Web API service. I am planning to use Basic Auth using SSL.
Could someone help me with below:
In future, I plan to have multiple clients including Android, iOS and Windows phone client. Any issues using Basic Auth over SSL?
Please help me confirm if below is right implementation approach.
I will write new Controller - AccountController in ASP.net Web API and use this controller for methods: Login, Logout and RegisterNewUser. All of them will be POST methods.
What should be code inside Login API apart from verifying user from database. Also should login method return any object to client?
Any reference which will help me understand client side of code, which will send authorization token on every web api request? Note: I am heavily using jqGrid with CRUD operation, which will make API requests.
There are no problems using Basic Authentication using these clients as far as I know. I have tested this scenario with Android myself.
I have just successfully implemented Basic Auth using this link as a resource:
http://www.piotrwalat.net/basic-http-authentication-in-asp-net-web-api-using-message-handlers
/Rune
1) There's no problem using SSL and Basic Auth together.
2/3/4) That would be a valid approach, though I'd recommend that you create a new MVC project and look at the generated code in the AccountController.cs file. This will give you some guidance on how to code these actions.
I want to write a web service using Visual Studio. The service needs to support some type of authentication, and should be able to receive commands via simple HTTP GET requests. The input would only be a method call with some parameters, and the responses will be simple status/error codes. My instinct would be to go with an ASP.NET Web Service, but this isn't an option in C# 4.0 and it makes me wonder if I should be using something that's more up-to-date. I've looked into WCF, but it seems like this requires a running application on the client-side - is there a way to query a WCF host by just accessing a URL?
The authentication is also an important piece. Developing my own little authentication system seems like a bad idea - I've read that it's too easy to mess up. What would be the standard way of authenticating with a web service like this?
I'd love to look up all of the specifics on this and learn it myself, but I really don't even know where to begin. Some direction would be greatly appreciated!
For a simple HTTP service that takes commands via GET (you should actually consider using POST...) I would use straight ASP MVC, not a true
'web service'. WCF wants to guide you down the path of SOAP and your clients will curse you forever. RESTful WCF is also an alternative, but it still seem overkill imho.
As for authentication, you have two viable authentication schemes:
Windows Integrated security, which will work only if client is inside intranet or connected with a VPN or DirectAccess solution
HTTP Digest, which is poorly supported by the ASP authentication modes (only support authenticating against a Active Directory forest user base).
With Windows authentication you don't do anything on the server side code, simply mark the the web.config <authentication mode="Windows" />. 'Windows' authentication is understood by most user agents. Is trivial to program clients of your service to use Windows authentication too, simple set the request's Credentials to the current user DefaultCredentials.
With Digest authentication the server will challenge the user agent to authenticate, but the ASP validation unfortunately, as I said, only works for validating a trusted NT domain. The client though does not need to be in the intranet (there is no NTLM SSPI exchange between client and server). Programming a client is faily easy, in .Net simply set the requet Credentials to a properly initialized CredentialsCache:
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://www.contoso.com/"),"Digest", new NetworkCredential(UserName,SecurelyStoredPassword,Domain));
...
request.PreAuthenticate = true;
request.Credentials = myCache;
It is important to reuse the cache between requests, otherwise the client will do two round-trips with each call.
In theory you can also have a third authentication path: full duplex SSL. But the 'trivial' problem of client certificate deployment makes this alternative a dead end for anybody short of a fully pre-installed enterprise PKI.