I would like to use oAuth as a system to allow developers access to my API but not require them to pass through the login information.
There does not seem to be any good how-to's or blogs on this topic. Everything I have found is based on consuming an oAuth system such as Facebook or twitter. Wondering if anyone has any links to good instructions or libraries that could get me started. If there are no examples out there perhaps someone could consider writing one, the community really needs it.
Using OAuth to login is actually a side-effect, not the main goal of the protocol. The best place to start with providing an OAuth-protected API is the protocol specification and since this is a new service, you should take a look at OAuth 2.0 1. It is pretty much done and ready for deployment.
To implement OAuth 2.0 you will need to make a few important decisions about which features you are going to support and your scaling needs. There are also a lot of security considerations to go through. I would suggest you start with supporting the authorization code and implicit grant types.
I would look into DotNetOpenAuth. It should work for your needs, but I've only used it for the OpenID stuff.
Related
I'm rather new to Web development so bear with me.
I've developed a backend server in C# (non-web app) that exposes some features via a REST API implemented in Web API (OWIN and Katana).
I've developed a Xamarin android app the consumes that API.
Now I want to enable the consumption of the API only for users who have authentication using Google.
I know OAuth is the way to do it and I've been reading a lot about it but I'm still kind of confused about the roles here and who should do what.
What should my server do or implement? what should my client do or implement?
An important feature of OAuth2 to be aware of is the two different authentication flow types:
implicit auth flow
explicit auth flow
I've personally found the Instagram API documentation to explain this pretty well:
https://instagram.com/developer/authentication/
Explicit auth flow is a little more tricky because it involves extra coordination on the part of your custom API. Implicit auth flow is a little easier, because your app will simply look for a URL fragment that comes back from the OAuth provider. That URL fragment contains a token that you can use for subsequent calls to the API that you want to talk to, Google in your case.
But in your case, it sounds like you want to use Google as the identity provider for your custom API, correct? In that case, I think you'll need to use explicit auth flow. Again, check out the Instagram docs. I find them to be particularly good at explaining OAuth2.
EDIT:
And be aware of the Xamarin.Auth component, which is designed for easing OAuth scenarios. You can find it in the Xamarin Component Store or on Github.
does dotnetopenauth allows or has the ability to run own identity server?
We are interested in building a id provider such as stack exchange, google, or fb.
As well as authentication, we are interested in allowing users to register and then using same creds, accessing corps any resource without login again and again.
what s the best place to start? any source code to research for such impl?
Yes, indeed it does!
Best place to start would be the samples included on GitHub.
OpenID Provider
This example will show you the basics for setting up an OpenID provider.
OAUTH
An example of protecting an API with OAUTH - including an example implementation of an Authorisation Server
Have a look, it's a deep dive but worth it if you are serious about being an ID provider - a decision which should not be taken lightly. If you need help then search/post back here on StackOverflow, post on the Google Groups or talk in the JabbR room
I want to guard OData service with custom authentication associated to a user table in database. I have been obssessed with this problem and searched solutions for a long time in vain. I mean, yes, there are quite a lot articles on the web but they are just quite trivial, for example implementing IPrincipal or IHttpContext with basic authentication on. Notably, many of them can data back to 2010 where OData is not as mature as today. So I'm wondering if there is any rapid solution to database-based custom authentication.
Any guidance would be greatly appreciated!
OData and authentication (and even authorization for that matter) are unrelated for the most part by design. That doesn't mean that OData stacks can't provide good support for authentication and authorization, just that the OData protocol itself doesn't comment on it. Protocol aside, both Web API and WCF Data Services are working on getting better support here. Speaking as a member of the .NET community (and not as a Microsoft employee), I think it's reasonable to expect that as those stacks implement authorization APIs they will probably be looking to claims-based authorization. Again, I want to state explicitly that I'm not trying to hide or divulge any plans here - I'm merely speculating about where authentication and authorization are going.
In a nutshell, if I were in your shoes I'd find the easiest intersection I could between OAuth2 and claims-based authentication and make that work for now. Working out your claims and authentication now means that you only would need to consider integrating the actual authorization code later.
I am struggling trying to pick apart the OAuth Service Provider example which is included in DotNetOpenAuth. I searched SO and found a few similar/related posts, but nothing really useful. Is there any open-source project or really simple/primitive example of an ASP.NET MVC 2 OAuth Service Provider? All I want to use OAuth for is authentication of the service. I was going to roll my own api with a key/secret, but thought a tried and tested protocol like OAuth would probably be a better solution.
I ended up doing some extensive research to find that I didn't need the traditional 3-legged OAuth and only needed 2-legged. The problem is 2-legged OAuth information is pretty hard to find. I finally found an Google spec for implementing 2-legged OAuth:
http://oauth.googlecode.com/svn/spec/ext/consumer_request/1.0/drafts/2/spec.html
I also found an implementation of it, as Justin.tv is using it for their services:
http://apiwiki.justin.tv/mediawiki/index.php/OAuth_Ruby_Tutorial
I also stumbled across an excellent OAuth testing tool which helped me greatly in implementing the service:
http://term.ie/oauth/example/client.php
2-legged OAuth is pretty simple once you understand what you are looking for and how to implement it. If you're searching for OAuth, most likely you are finding articles talking about the traditional 3-legged OAuth which involves 3-parties as the name implies: consumers, service providers, AND users. Two-legged strictly involves consumers and service providers. If you're service does not deal with users specifically, 2-legged OAuth is just what you're looking for.
As for a framework, I am using ASP.NET MVC so I ended up settling on a github repository located here:
https://github.com/buildmaster/oauth-mvc.net
Its got some really nice, clean code, and uses dependency injection (Ninject). It didn't take much for me to be able to modify it for 2-legged OAuth.
It should be possible to use SAML to authenticate users for any type of application (according to the spec), but the examples I have seen are cookie-based ASP.NET web-sites.
Does anyone know of an example authenticating users for, say, a Win Forms app (not using cookies)?
Not quite sure what it is you are looking for. If you are looking for SAML based authentication, you can use some combination of Windows Identity Framework and WCF and AD FS. SAML is just the "language" of authentication, but unless you already have an identity provider, you need to start there first.
You can use this article to give you an idea of what the basic infrastructure looks like, and I frequently use the site leastprivilege.com for a deeper reference.
But, if the scope of your application is purely within the desktop (ie, never communicates with any services) you really don't need anything like SAML to achieve your goal. Usage of tokens like SAML are for communicating with web services where the endpoints trust the identity provider.
SAML is a wee complicated beastie. I'm not sure I'd try to roll my own SAML SSO solution.
When we implemented SAML SSO, we used PingFederate from. It's expensive, but good. There's also some open source SAML SSO stuff about, but I can't really speak to it.
PingFederate is pretty dead simple to configure and use, although if you don't speak SAML, the learning curve will be steep until you understand the concepts, the flow and the lingo used.