So I have been looking into OAuth lately, I want to authorize another of my domain which has separate database using OAuth. Upon searching I found auth0.com. Which sounded similar to Oauth and I created a sample implementation, it offers support for custom databases also. We have users stored in external api running on .net core, and I learnt that auth0.com is not free after trial expiration. So my efforts kindof got wasted. Now I am looking for authorization method that works for both domains.
Now my question is, does it even make sense to use Oauth for this task? Since I won't be giving it to third party and it's matter of two databases. How should i approach this and what are opensource Oauth services that allow custom database.
Related
I have been tasked with creating a Web API for our mobile application and future 3rd parties to use in order to access our data, etc.
That alone is simple enough, but then I need to secure it. Initially, after reading about OAuth and doing some research, I decided to go the home grown token based route utilizing best practices found online for security. My prototype worked wonderfully but unfortunately the company wants to use OAuth since it's a recognizable standard and considered marketable to our clients.
Soooo, after banging my head against multiple walls the past few days I am curious if anyone has an implementation using OAuth as a service provider and then an ASP.NET Web API client as consumer.
The workflow envisioned is that the mobile application would hit the API which in turn would expect token(s) issued from our self-hosted OAuth service provider. I've yet to find any comprehensive documentation or examples online about this. So far everything I've seen is very piecemeal and therefore incredibly frustrating trying to implement anything.
Well - there is the OAuth spec of course (since you seem to like to handcraft things ;)) https://www.rfc-editor.org/rfc/rfc6749 and the corresponding threat model - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-threatmodel-08
Our OAuth2 authZ server / sec library has an implementation as well - I compiled some docs here: https://github.com/thinktecture/Thinktecture.IdentityServer.v2/wiki
I feel a bit overwhelmed right now with how to approach building an SSO solution for a project I'm taking on. I understand that I need a centralized login site, but, I'd like input on what framework I should be using to achieve this. I've been reading a bit about Windows Identity Foundation (WIF), but, the lack of documentation and code samples is quite disappointing. DotNotOpenAuth sounds like it has much more usage by the community than WIF, but, I'm not sure if that's the right framework for me to use given that I am not going to be letting third-party accounts be used for logging in.
There are multiple user data stores to take into account as well; active directory and a SQL Server database.
I really don't care what framework I use so long as it's simple and intuitive; I don't want an overly complex solution. Documentation and samples are also a plus! I already have experience with creating custom role providers and membership providers; those were a breeze and easy to do.
Here is a very quick visual of the structure I'm dealing with:
Refer: Claims Based Identity & Access Control Guide and Identity Developer Training Kit. There's WIF samples there.
In terms of what you want to achieve, ADFS v2.0 will get you most of the way but it can only authenticate against AD. For SQL server, use IdentityServer and then federate ADFS and IdentityServer.
Have a look at SAML. It is designed to address SSO. You may also want to look into OpenID.
There are enterprise products out there, such as CA Site Minder or IBM Tivoli for this kind if thing. They are not cheap because building a custom solution for this will be quite a feat.
If you are .NET based - then .NET 4.5 (which includes WIF) is the way to go.
But the framework will be you simplest problem. Building that kind of security infrastructure is hard. Have a look at both the book and idenitity server from nzpcmad's answer as a starting point.
As far as cross-platform goes, SAML tends to lead the pack. There are many implementations (java, php, perl). As Dominick (#leastprivilege) mentioned, if every application is .Net based, WS-Fed via WIF is the way to go. (btw, Dominick is the man when it comes to WIF - definitely hit his blog and forums up if you plan on exploring that route)
OpenId and OAuth are alternatives that you will hear about. They are somewhat less secure (the trust is in the user, rather than the infrastructure) and you will find that you will have to build a provider in order to support sign-in using your own user store.
Regardless of the route you choose, be prepared to do a lot of reading and learning. Check out the wikipedia articles above for a nice overview of how these technologies work, and don't be afraid to ask questions..
I'm trying to secure my MVC4 Web Api. Actually, I just really need an identity provider with some light security. My service is similar to twitter, from a security standpoint, there's not a lot of private data, but the service does need to know the userid for the caller.
It's also important to know that the web service will only be consumed by mobile devices right now, although a website may accompany it at some future point.
S.O. and the internet have led me to Thinktecture.IdentityModel, but man it seems complex and I can find exactly zero documentation or samples. I also haven't yet had a pleasant experience with claims-based authentication. I don't have a claims server, token provider, or anything like that, and it seems like you would need that to use this method. This all seems far to heavy for my situation.
I've also read about people implementing their own HMAC solution (https://github.com/cuongle/WebAPI.Hmac) or using OAuth (https://github.com/maksymilian-majer/DevDefined.OAuth) but these also seem a bit complex (I've read that OAuth without the helper class is enough to make the best developers cry, and I'm not the best). Janrain looks like it might work, but it looks like you have to pay for more than 2,500 authenticated users per year ...
What is the best way to implement a simple identity provider and security for Web Api?
Thanks!
I have attempted to answer a similar question to this before Create an OAuth 2.0 service provider using DotNetOpenAuth where I highlighted the Thinkecture Identity Server. The Setup instructions not too difficult (IMHO) The installation video is here and should help a lot.
I have updated my older answer with this too but there is also a fairly lightweight O-Auth 2.0 implementation example here Sample code here http://code.google.com/p/codesmith/downloads/detail?name=OAuth2.zip&can=2&q=#makechanges
Have you also read this well articulated question here Authenticating requests from mobile (iPhone) app to ASP.Net Web API (Feedback requested on my design)
Well, security is hard :)
As for Thinktecture.IdentityModel -- this is a token processing library (among other things) that you'd use in your WebAPI application. You'd use this so you don't need to do the logic to accept tokens (basic auth, SAML, SWT, JWT). Claims are just a side-effect.
If you're looking for an identity provider, then the sister open source project Thinktecture.IdentityServer is in beta for version 2. It's an identity provider that supports a custom database and issues tokens. The project URL is:
http://thinktecture.github.com/Thinktecture.IdentityServer.v2/
In response to the problem of finding example code as documentation, consider the samples folder in the Thinktecture github repo: https://github.com/thinktecture/Thinktecture.IdentityModel.45/tree/master/Samples
(Why do you need more reputation to comment on SO than to answer?)
I am in the process of re-writing some very outdated .NET 2.0 SOAP web services for my company. So I am rewriting them using MVC3 RESTful. This method would simplify the usage of our services for our client base (over 500 clients using our current SOAP services) who are on multiple platforms and languages.
I am looking for a BETTER method of authorization for the RESTful services, than what the previous developer used for our .NET 2.0 SOAP web services (he basically just had the client pass in a GUID as a parameter and matched it in code behind).
I have looked into oAuth and I want to use it, HOWEVER, I have been told, from my superiors, that this method is TOO complicated for the "level" of clients that connect to our services and want me to find another simpler way for them to connect but still have authorization. Most of our clients have BASIC to no knowledge of programming (either we helped them get their connection setup OR they hired some kid to do it for them). This is another reason that the superiors want a different method, because we can't have all 500+ (plus 5-10 new clients a day) asking for help on how to implement oAuth.
So, is there another way to secure the MVC3 services other than passing a preset GUID?
I have looked into using Windows Authentication on the services site, but is this really logical for 500+ clients to use?
Is there an easy and secure method of authorizing multiple users on multiple platforms to use the MVC3 RESTful services that a end-client can implement very easily?
Thanks.
If you don't want anything too complicated, have a look at Basic HTTP Authentication. If you use it over SSL then it should be safe enough and also easy enough to implement for your clients. The Twitter API actually used this up until a few months ago when they switched to OAuth.
You want to distinguish between authentication and authorization. What you are looking for is authentication and indeed as Caps suggests, the easiest way may be to use HTTP BASIC authentication along with SSL to make the password is not compromised.
You could look into other means of authentication e.g. DIGEST or more advanced using ADFS or SAML (ADFS could be compelling since you're in .NET). Have a look at OpenID Connect too - it is strongly supported by Google and has great support.
Once you are done with that, you may want to consider authorization - if you need it that is - to control what a given client can do on a given resource / item / record. For that you can use claims-based authorization as provided in the .NET framework or if you need finer-grained authorization, look into XACML.
OAuth wouldn't really solve your issue since OAuth is about delegation of authorization i.e. I let Twitter write to my Facebook account on my behalf.
HTH
We are currently using an outdated screen scraper gem to import contacts from gmail/yahoo/etc. I want to update this to use the new OAuth based APIs so users don't have to enter their credentials on our site. I'm really intrigued by the work Plaxo is doing with Portable Contacts which Google also supports. It feels like that is a good direction for read-only access, and it is still backed by OAuth.
Are there any compelling reasons to just go with the standard OAuth API for these providers instead of going the Portable Contacts route? I'd like to know if there are strong reasons to avoid it. I'll still be using straight OAuth for the ones that don't support PC so it's not a question of development time, more one of support and confidence in the new approach.
The idea is that each OAuth implementation will be slightly different where as each Portable Contacts implementation will be the same. It's kind of like a REST API (OAuth) vs. a SOAP API (Portable Contacts --but with the same overhead as OAuth).
So you should theoretically be able to make one Portable Contacts Reader and hook it to any provider who supports it with no additional work.
In reality for now, you'll probably need to work with both Portable Contacts and OAuth-non-portable endpoints. (With most OAuth-non-portable providers hopefully moving towards Portable Contacts).
OAuth Core doesn't define either discovery (leading users to the OAuth URL which will let them authorize the resource to the consumer) or representation (informing the consumer about what authorization the token will provide). Without a spec such as Portable Contacts, these need to agreed upon ad-hoc by the consumer and provider (with discovery probably being simplified to a well-known URL). So Portable Contacts is just answering those questions once for each provider which uses them. You'll need to work out the ad-hoc answers if you want to support providers which don't, but you'll be using the same OAuth Core implementation for all of them anyway.
Portable Contacts itself builds on the OAuth Discovery spec, which seems to be expired without a replacement, unfortunately.