I have spent the past three days researching OAuth 2.0 and I understood how OAuth can be used to interact with a service provided by a heavy weight such as Google or Facebook. However, I'm struggling to see how someone without a team of tech wizards (aka Me) goes about protecting their API with the protocol.
I have a number of questions and was wondering if someone with some experience can help me.
Here goes nothing...
Is there a clear cut leader in terms of an OAuth Authorization Server implementation (Java)? If yes, is there any good resource out there to teach me how to use it?
Its my understanding that I would need to either build an authorization server or leverage a library to dish out client secrets/tokens.
Should I even be thinking about a library or should I be building my own implementation?
Is OAuth still relevant? From what I can see, it seems like the hype around the technology has leveled off or diminished since 2010. I also saw an article where the spec lead disassociated himself from the protocol.
I appreciate any advice or help, I can't find many resources on this topic that address it clearly (tons of Powerpoints, no code). There seems to be a bunch of talk about how it works, yet no book or article can give a solid tutorial. The documentation for the providers I have found is also very spotty at best. I'm just really starting to question whether this is a legitimate undertaking for someone looking to protect their own simple API. Thanks ahead of time.
Take a look at the Libraries on the OpenID Connect developer pages here: http://openid.net/developers/libraries/
I don't think there's a clear cut leading Java implementation yet
I would not recommend implementing the Authorization Server part on your own, that is the complex part and details matter because this is about security; the client part is easier and should be possible to build even without a library
OAuth is very relevant as it is the only standard out there for securing REST APIs; the hype is over, and now it is common technology; just take a look at all big vendors/SaaS out there, they all use it (starting with Google, Microsoft, Facebook, Twitter etc.)
Related
https://developer.microsoft.com/en-us/office/blogs/end-of-support-for-basic-authentication-access-to-exchange-online-apis-for-office-365-customers/
Our organization is finding this announcement somewhat problematic! We use an IMAP library extensively to read various service based email accounts in o365. Any guidance on how to address this would be greatly appreciated.
Note, we have many console apps written in .NET (4.8) that run on a server based fired by many scheduled tasks. I understand we'd need to somehow register our "application" (I'm assuming that can be a generic one for our company), but we cannot involve any "user" interaction. These are utility apps. Glancing at the existing sample code for OAuth, they all seem to involve popping up a browser window to get someone to interact with "asking permission" which is exactly what we need to avoid.
We've used IMAP all this time to simply read and parse service based email accounts. I'm not sure I understand why IMAP over a secure connection is "less secure" than a more complex solution. Why take the option away?
On the other hand, the Microsoft Graph API looks significantly more complicated and appears to be OAuth based which, again, seems to involve quite a bit of authentication complexity.
Most REST APIs we've interacted w/ in other .NET console apps use a simple set of API "keys." Why not offer that at least?
As I say, we're looking for a way to write some process that run programmatically to automate a number of operations related to certain mailboxes. IMAP has worked like a charm so far, so we're looking for direct guidance on what to migrate to.
We understand your concerns. While a secure IMAP connection protects the data that's being transported, Basic Authentication exposes your Exchange Online accounts to attack techniques like phishing or brute forcing.
The primary objective of this change is to protect our customers from these threats. In addition, Modern Auth enables admin visibility into app access and enables fine-grained control of these apps.
To answer your question on implementation guidance, there is an existing approach in Graph to achieve exactly what you're looking to do. It's called "OAuth 2.0 client credentials flow". You can read more at https://learn.microsoft.com/en-us/graph/auth-v2-service
(Disclosure - I'm a Senior PM at Microsoft)
I'm trying to develop an open source solution which will be deployed on Raspberry Pi's or similar SBCs. The RPi part is only relevant insofar as it means all the code and app resources need to be publicly available.
The solution needs to read Twitter statuses, as close to real time as possible, and with as little interference from third parties as possible. I found Twitter's Streaming API, which is blazingly fast, and would be perfect for my application – except it requires OAuth. And as far as I can tell, the OAuth mechanism isn't well suited for deployment on users' machines, since it relies on a secret key which belongs to the application owner (the consumer secret).
I couldn't find any easy way around this – the only solutions I could think of are either handling request signing on a central server, or asking each user to create their own Twitter app account. And I find both solutions terribly distasteful.
Do you see any elegant way out?
It turns out this is indeed not currently feasible cleanly with any of Twitter's public APIs; not now, and not in the foreseeable future. Refreshingly, for once we do have proof for a negative: I also asked this on Twitter's own forum, and I was lucky enough to have my question kindly answered by Andy Piper, Global Lead Developer Advocate at Twitter. There you go.
Your app can open a web browser with Twitter's application authentication webpage loaded. When the user enters their credentials Twitter will return a code which they can copy/paste into your app. It's not particularly elegant. Here is a Python example of the workflow: https://github.com/geduldig/TwitterAPI/blob/master/examples/oauth_test.py
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?)
Does anyone know of an example facebook app (or facebook connect app) done in Erlang? I'm looking for something that includes the whole process. Specifically I don't seem to find anything on user authentication.
I've checked out erlang_facebook, erlang2facebook and erlyface but none of them seem to offer a simple and comprehensive example accessible to me as a beginner .
I'd be happy for just a bit of code to plough through though, preferably using mochiweb as backend.
I've played around writing a FB app in Erlang and looked at the projects you mentioned as well. I found it easier to just use FB's graph API directly for authentication, etc. I used Nitrogen/Mochiweb for the web server and made graph requests with httpc:request.
Zotonic (Erlang CMS/Framework) provides Facebook integration, including authentication.
http://zotonic.com/mod-facebook
A few years on and I still find Jeremy Raymond's method satisfying. In particular, wrapping their ever-changing url-as-an-API scheme inside your own API seems to be the most painless. httpc is useful, and so is cowboy if you are familiar with that.
Whatever you choose, you should absolutely not be designing your ideas around their API. Convert their ideas into your project's semantics by wrapping their API. After all, the web isn't the whole internet and you never know when FB might stop being the cool place to waste your life. There is no telling if your application/library/codebase-you-use-on-something-else will outlive theirs.