A Different Kind of OAuth Blog
I will be writing about my experiences delivering an OAuth Architecture for a Financial Company. My posts will cover topics related to the following areas of business value:
- Solid Architecture for UIs and APIs
- Modern Enterprise Security Behavior
- Cross Domain Connectivity
- Login Usability for your End Users
I will focus on Ordinary Software Engineers and What Companies Want rather than solely on Security and Coding. This is a detailed blog and not the gentlest of introductions to OAuth technologies.
Basic OAuth coding is pretty straightforward, but making the right Design Choices and getting past Blocking Issues can be difficult. If you are struggling, I hope the details and visualization in this blog are useful.
Getting Started …
Recommended Security Standards
The Identity Server website has a very nice summary of why OAuth 2.0 and Open Id Connect are the preferred standards for securing modern applications.
I will use a number of resources from such security experts – in particular their OAuth Code Libraries – but this blog will avoid most OAuth jargon and instead use everyday software terms.
Goal 1: Single Page Applications and APIs
A common goal for companies who want Modern High Performance Web UIs is an architecture that looks roughly like this, with a clean separation between delivery of API Data and Web Content:
It is a simple concept, but the difficulty is that UI requests to APIs must now provide a cross domain credential – and the standard solution is to use OAuth 2.0 based logins that provide access tokens:
Goal 2: Adding Mobile Apps
The next step for the company might be to extend their product / architecture to include mobile apps as well as web apps – there can be great business benefits in having an App Store presence:
However, this requires the company to extend their OAuth capabilities to cover iOS and Android devices, and there can be a big learning curve.
Goal 3: Federating with Business Partners
The biggest benefit of an OAuth architecture is often the great connectivity and extended reach available to your products. The potential exists to securely compose UIs and data with your business partners:
This can provide a great experience for end users, with access to live multi domain business data. Federation can also significantly improve the Login User Experience.
Goal 4: Operational Success
Your UIs and APIs will now be interfacing with more middleware than previously and you will want to ensure a Reliable Rollout.
Companies want to get a good balance between Security and Usability. In particular, companies will care about the Login User Experience, with features such as Automatic Sign In and 2 Factor Authentication.
Most Online Articles and Code Samples do not cover the Real World issues that many companies will face:
- Migration of Large Existing Products to OAuth based technologies + tokens
- Choosing good Third Party Middleware, and gaining a deep understanding of what you want from it
- Making the right Technical Design Choices for your company, to reduce Future Costs
- Providing Good Login Usability, so that your Business and UX Design stakeholders are satisfied
Blog Deliverable 1: OAuth Design Recommendations
I will aim to cover features one at a time in quite a bit of detail, with a focus on simplicity and reliability wherever possible. I hope to keep the blog visual so that it is easy to follow.
Blog Deliverable 2: Code Samples with UIs and APIs
I will provide Web / Mobile / API code samples with instructions on how to run them. Essential features will be implemented in line with blog posts.
I want these samples to be fairly complete, demonstrating Good Library Choices, how to implement Essential End User Features and the importance of Solid Code.
Blog Deliverable 3: Infrastructure Guidance
I hope to help developers take better control of Infrastructure, especially when we cover the Mobile and Federation Goals, to empower you to troubleshoot areas such as Networking / X509 / Kerberos.
Technology Never Works Perfectly!
When you first start working with OAuth you tend to run into problems like this, and you may need to find the ‘least bad solution’:
- OAuth Standards don’t always support the behavior you would like
- Vendor Authorization Servers are not always Standards Based
- Security Libraries don’t always work perfectly with Vendor Authorization Servers
Our goal is to write Zero Real Security Code ourselves, and delegate it all to 3rd party libraries written by the likes of Google, or to the Authorization Server.
I hope to get some great feedback on places where my ideas are incorrect, unclear, or you have a better solution. Any reader is more than welcome to post comments.
Where Are We?
We have stated our High Level Goals and our first objective will be to deliver a Code Sample where an SPA and API interact using OAuth 2.0 technologies.