Episode 042 | Creating Office 365 Applications using Azure - An Interview with Scot Hillier

In this episode AC & CJ interview Scot Hiller to talk about a new pattern in creating Office 365 applications using Microsoft Azure & Azure AD directories.

Episode Hosts:

Episode Guests:

Episode Notes:

Episode Transcript:

[0:02] Robin Williams: Gooood Morning Vi-et naaaaaam! Hey, this is not a test, this is rock and roll! Time to rock it from the Delta to the DMZ.

[0:12] Andrew: This is the Microsoft Cloud Show Episode 42, where today we're going to talk about a new pattern for creating applications for Office 365 in an interview with Scot Hillier. Recorded live August 13th, 2014.

[0:28] Andrew: Welcome to the Microsoft Cloud Show, the only place to stay up-to-date on everything going on in the Microsoft Cloud world including Windows Azure, Office 365, SharePoint, Exchange, Lync, and related technologies. Just the information, no marketing, no B.S. I'm Andrew Connell.

[0:45] Chris: And I'm Chris Johnson.

[0:46] Andrew: And we're just two dudes telling you how we see it.

[0:50] Andrew: Good morning, CJ. How are you?

[0:53] Chris: Very well, thank you, AC. Very well. How about yourself?

[0:56] Andrew: Doing good. That was my very solo and short tribute to the now recently passed Robin Williams. That was a—that's a major bummer, man.

[1:07] Chris: Nanu, Nanu.

[1:08] Andrew: God! That was a major bummer. There are—aside from people who are close to you, people that you hear about that if—that are no longer with us, very rarely this—it really affect me. I was looking at my wife last night and we were seeing some of the stuff on the news, talking about Robin Williams and I think there's only one other person that has really bothered me, their passing really, really bothered me. This one was—I just found myself just kind of like going back and watching clips of his movies and stuff and just—the sounds really—this might sound kind of sappy but just getting sad.

[1:44] Chris: Yeah, I know what you mean. I know exactly what you mean. It was very sad, very, very sad. And so, it's so unfortunate that some of the funniest people in the world are so torn up inside.

[1:58] Andrew: You know, I saw a session at a conference I went to a couple months ago and this guy, it was this—it was a startups kind of a conference and this guy was talking about like mental health and stuff and he said that some of the greatest minds suffer from a mental health problem like the Michelangelo and the Beethoven and all those guys, some of the best guys or some of the best people, most creative and people have been—have had so much to contribute to our society, how they had a mental illness and like it's kind of weird that there's—I don't want to say correlation but let's just say coincidence because I don't think you have to have a mental illness to have a huge contribution to society but it's just interesting to sit here all the people that, you know, where that's been an interesting coincidence.

[2:47] Chris: There's definitely something that comes with being ultra creative or a genius that that I think makes or leads to a strong susceptibility to mental illness.

[3:00] Andrew: Yeah, oh well.

[3:01] Chris: And I know a few folks—I say a few may sound like a lot but a couple of folks close to me that are—that suffer the same sort of hyper-creative but also hyper-susceptible to depression.

[3:16] Andrew: Yeah, it's challenging. But, yeah, so not with us anymore but they gave me some—gave me some great memories so thank you very much Robin Williams.

[3:28] Chris: Yeah, likewise.

[3:29] Andrew: Okay, so let's on with the show here. Before we dive into the meat of the show here, we got a little bit of—I guess, news and updates and stuff. So, let me first start off with you, CJ, you know, what have you been up to in the last week or so?

[3:46] Chris: I was off on vacation last week over in Lake Chelan, Eastern Washington. So, going out on a boat on the lake and hung out and took some—I don’t know, after the crazy event season that has been. So, thoroughly enjoy that. And then just before that actually, right before I went away on vacation, I did a tour of the Microsoft Operation Center—the NOC, oh sorry, the Microsoft Network Operation Center, the NOC. And this is a place—there's a few of them around the world, a undisclosed number of them around the world, and it's basically where Microsoft runs its network operations from, right. So, all of the networking and infrastructure for all of its cloud services, for all of its web properties through that, everything from Xbox Live through to MSN through to Office 365, all of those things and all of its internal network around the world and the network that are uses to run all those online properties and all of the gateways to the internet around the world that that network has.

[5:03] Chris: And so, it was absolutely fascinating and just hearing about how the network is run—and I actually, I got to two other center with a couple of folks from Nintex that I arranged the tour for and so we went and heard from them about what happens in an incidents and how things work and all the different teams involved and what happens and then we got to two other sort of dark rooms with lots of people tapping on keyboards and lots of blinking lights and big monitors up on the wall and all of that sort of stuff and seeing the day to day operations of what happens in a place like that, which is, for me, was really interesting because I haven't seen a lot of that stuff before like that and I found it fascinating.

[5:51] Andrew: I love those things. I love like the—I guess, behind—it's not so much of behind-the-scenes to see how the sausage is made but it’s just how you run the business and with an operation that is so significant. That's it's fascinating. I have been able to do that one time, been able to do that one time but it was a very long time ago when I was working for financial services company that serviced over half the mortgages for the—of all mortgages in the United States between all the different banks, but—and then I did it again, I guess, earlier this year with the mission control for the JPL, the Jet Propulsion Lab, but I think that seeing these different—there's this theme that you see where more and more companies have like this engineering blocks and they're exposing more behind-the-scenes of what they do and the thoughts that go behind and it's not so much like what you saw but the more coverage of somewhat transparent about that you get a—like I think that you get more reassurance from those companies when you understand what some of their processes are and like for example, like a—it was at Netflix where they've the engineering block, they go so much to show, so much of stuff they do and everyone's familiar with their—what's it called? Chaos Monkey and all that stuff.

[7:06] Chris: Yeah, Chaos Monkey, yeah.

[7:07] Andrew: So, the SimianArmy.

[7:09] Chris: I was just—I was stunned you know, we asked questions about failover like what happens in certain situations and things. You know, these guys are on a building on the main Microsoft campus. This is where the Redmond base NOC is, and they've got it down so that even if there's—even if they need to shut the power off to this building then that can—the NOC can failover to another location on the main campus and then if main campus is out for some reason then they can failover to a NOC in Bellevue and then if the Pacific Northwest disappears below the ocean then they can failover to a number of different NOCs around the world, one being Hyderabad, there's another one in Europe and so forth. And so, like even if—even if something really hyper local happen they can go elsewhere on campus and still continue operations. They can go to Bellevue which is only a 10-minute drive away and then if those are down then it goes offshore. So, it's interesting.

[8:13] Andrew: That's like real world Jack Bauer 24 like, send it over to my screen.

[8:18] Chris: Yeah, and just interesting seeing how the different services are segmented. So, you know, Skype has obviously teams that run the Skype system and they're all integrated as well but there's different NOCs around that specifically deal with certain services like Xbox Live, Yammer, Skype and so forth. So, it was really, really interesting and it's amazing to sort of have a little peek behind the curtain and see how it all hangs together.

[8:47] Andrew: I have one question about it. Is there a big red, holy—button on these things?

[8:56] Chris: Yeah, I don't see one. I got to tell you, but—you know, one thing that really surprised me was that—so, it's a 24x7 operation, right. There's obviously somebody in that room all the time and it sort of follows the sun around the world, right. But, you know, I never really thought about it all that much about what it takes to run a network of that size and that complexity, but they had different people on different effectively teams like some would be doing routing and some would be doing security stuff and some would be doing different things and so each sort of teams is quite segmented. So, it's almost like there's sort of five little NOCs in one, so to speak. But, no big holy—button. And I don't see any big red easy buttons either. So, it all looked pretty hard to me.

[9:45] Andrew: There was a—actually I forget the old one. I have been in a NOC, it was with the Department of Defense, so one of the security agencies or one of the intelligence agencies for the Department of Defense, I used to—I worked there for about a year and I was there when the second Iraq war started, the night that the war started. It was on—I maintained like two or three different systems and so I was on what's called the Essential Operations List and there was a special lane on the highway for—not special lane but there's a special traffic pattern on the highway right outside the base to get us in and everything and when we knew—we anticipated a war starting and if the war start we were supposed to report in right away and—I won't go into too much detail of it just because I don't think I'm suppose to but I do remember seeing that there's different networks with the Department of Defense, where there's one called Super Net and Nipper Net. Those were not to the internet except at specific point. So, they can kill the connection to the internet and still have an internal Department of Defense network watching the attacks coming in from all the countries that you would have regularly expect to try to penetrate our network. Watching it skyrocket when the war started was fascinating.

[11:00] Chris: Interesting, interesting.

[11:02] Andrew: Yeah, there are definitely somebody in the room that they might not have had the Holy—Button but the Holy—Button. I'll make sure I'll censor some of this stuff out. Need to go find a better censoring noise. Yeah, so that's cool. I've been—I guess, for me, I've been working on—I got a project actually that recently just went—that went live that was actually part of a—done for a part of your team. That's something we're going to talk about. So I'm going to come back to that in just a minute but I guess for news related to me, I'm doing actually a SharePoint 2013 Application Developer class or SharePoint App Model class in Tampa in early October for Critical Path Trainings.

[11:50] Andrew: So, if anybody is interested in joining me down in Tampa, October the 6th to the 10th. And I've been also diving in quite deeply into the Patterns & Practices stuff that your—that's come out of the Office 365 team that's all up on GitHub, so it's—I'll you what man, I know that I keep saying you guys because I guess it's part of your organization but those guys created a bunch of samples that originally were in CodePlex, they have since moved over to GitHub and it's really—they're really good samples, there's lot of good codes were used, there's like a central library and then lots of samples and scenarios that leverage the sample library for some reusable pieces, man, I'm sitting here this morning working on some stuff. I noticed two or three things that I thought should have been different. I made a few—I forged the repository, I made a few changes, committed them to mine, submitted a poll requests and within about two hours my changes have been merged in, now granted they were not major but it was pretty cool.

[12:57] Chris: Yeah, that's been a really—you mentioned it was on CodePlex before, we use CodePlex as a publishing point but it wasn't open-source and the fact that you couldn't submit the equivalent of a poll request, right. So, you couldn't submit changes to the code and that was very much sort of a one-way street, right. It was a bunch of folks internal sort of led by Vesa and Steve Walker, who are publishing these things and it was very much about just getting it out and we've been working for the last couple of months on a) scrubbing it all up and getting it ready for release then also moving it over to GitHub and the team are in the process of migrating all of the documents that were in docx format over to Markdown and things, so it's all really easy to submit changes not only to the code but also to the documentation and the uptake—well, the pickup and that's been really interesting.

[14:00] Chris: I think I was talking to Jeremy Thake, who's on my team yesterday, and he said, I think we've hit it like 1500 unique users in the last like week and half or something on that repo, and I can't remember how many poll request he said that we've already had from folks who submitted, but it's great to see, right. That's the whole point of sticking it on GitHub and open-sourcing, it was so that people could submit bug fixes or features or documentation changes and it's really cool.

[14:34] Andrew: Yeah, I think it's only been on CodePlex now for like a week or two and I'm looking it right now and including mine, there's been 11—there's 11 closed poll request and one that's still open, but it's only been open for about five hours. So, that's really cool. It's really cool. We should do a show just on this one sample here because there's a lot of really good stuff here.

[14:56] Chris: Yeah, for sure.

[14:57] Andrew: Anyway, the other thing too, this is a quick bit of news before we do a little intro here is that I know you guys also, your team also shipped a update to the Office 365 API tools for Visual Studio 2013. We'll have a link to that in the show notes as well as the blog post that goes through all the improvements and changes and lot of bug fixes, but there's tons of changes in it as well and code changes around authenticating with the 365 sample—365 API.

[15:24] Chris: Yeah, and getting access to those things, using those tools from other platforms like Windows and things like that.

[15:29] Andrew: Yeah. Yeah, so—well, one of the—I guess the meat of the show's—we don't want to smack the show too, too long because I know we have an interview that I want to play here but earlier this week or—yeah, earlier this week I guess, on August 12, there's a blog post that we'll link to on the Office blogs the depth that—or the blogs.office.com site that includes two AngularJS standalone website samples that were shipped and they're on the OfficeDev GitHub organization account. So, you'll be able to get links to all of these.

[16:08] Andrew: One of them is an Expense Tracker application that was done by the very, very esteemed Dan Wahlin, who's traditionally a ASP.NET and AngularJS Single-Page app guy on the—that hasn't so much been in the SharePoint space but he did a really good sample for you guys that was published, but the one that I really want to highlight here that I want to talk about is one that I did a conjunction with Scot Hillier and it's around—we had—there's three different projects associated with it. Scot and I, we talked a lot about at the interview is—I interviewed Scot last week, talking a little about these samples but there's three samples, one is a Single-Page app using AngularJS, one is an Outlook web app extension for the Outlook web app and then one is a custom task pane for the Office—for an Office app, for a desktop app.

[17:02] Andrew: But the big things here that I think that that Scot and I sampled, what we had done is that we showed you in all of these samples to where we created these apps that interfaced with Office 365, in our case specifically SharePoint Online, but we didn't do anything at all inside of Office 365 and SharePoint in terms of configuration. All of them are based on having the same Active Directory that is shared between Office 365 tenant and in Azure tenant and we created an application in Azure AD and then did a single sign-on and did everything as just ASP.NET, MVC applications or whatever that talk—that did not talk directly to SharePoint, they talk to Azure instead and then interface straight back to Office 365.

[17:56] Chris: Gotcha. The interesting—one of the interesting things, it’s great project like it's a really, really cool reference project that or reference implementation, I guess, and interesting pattern that people should go use or look at least before they start their projects with Office 365, go take a look at. But one of the really interesting things about it from my perspective is that it's not only just a web application that goes and talks to Office 365 behind-the-scenes but that it's also components of the app land in Outlook and also in Word as well, right.

[18:40] Chris: So, you've got the main web application that somebody would use when they're setting up their desktop with a browser open but then also you've demonstrated how to connect part of that application into Outlook using the app model to do that and then also the same for Word as well. So, surfacing pieces of your application in different locations and I'm going to get a little marketechtury here but we called this like contextual apps right, where depending on what context you're in you want to surface different parts of your apps. So, when you're in Word, for example, you might surface a piece of your application that makes sense for that person when they're using Word and can be sort of ride alongside the document or the Outlook example that you guys have got is pretty cool too. So, when you're in a mail, it's contextual to that mail and you can take an activity or do an activity in that app right within Outlook. And so, that's that concept of kind of contextual pieces of your application in different locations. And, so what's cool about it is a lot of examples to show one of these things in a silo but this reference implementation shows an apps that spans all of that stuff together and connects the dots, which is really cool.

[20:00] Andrew: Agreed, yeah. So, we have a lot of different scenarios that we're trying to show here about different opportunities for developers to jump into but let's quit the going back and forth here. Let's go and just jump straight into the interview with Scot, I want you to also take note of a little bit of a discussion that we had around access token and securing those and after the interview we'll come back, chat a little bit more about it. So, let's go and roll the interview.

[20:23] Andrew: All right, so today we have a guest with us. We have Scot Hillier. Scot is a independent consultant and Microsoft SharePoint Most Valuable Professional focused on creating solutions for information workers with SharePoint, Office and related technologies. He's the author and co-author of 18-plus books on Microsoft technologies including Inside SharePoint 2013 and App Development in SharePoint 2013. Scot split his time between consulting on SharePoint projects, managing developer content on ITUnity, speaking at SharePoint events and delivering SharePoint developer training through Critical Path Training. Scot is a former US navy submarine officer, a graduate of the Virginia Military Institute and he can be reached at [email protected] and that's Scot with one T. So, how are you doing today Scot?

[21:13] Scot: Good, Andrew. Thanks for having me.

[21:15] Andrew: Absolutely, absolutely. So I wanted to have you on the show today to talk about something that you and I worked on recently but I'm going to let kind of run the show. You and I recently build a couple sample projects for Microsoft that are public and we'll talk about the links to where people can get them towards the end of the show, where we did some—kind of some new and interesting stuff and some new kind of application patterns. And so I wanted to kind of go over these with you a little and share some stuff with our listeners some challenges that you and I ran into and some things about why—well, I guess, more specifically why you find this interesting for our listeners. So, how does that sound out today?

[21:54] Scot: Sounds great.

[21:55] Andrew: Awesome, awesome. So, why don't you talk a little bit about what this Reference, we call it the Reference Tracker, the Research Tracker Project. Why don't you talk a little about what this is from a high level and what components we kind of leverage here?

[22:10] Scot: Yeah, okay so let me backup just a little bit here and just talk a little bit more generally about SharePoint development and what's going on these days. I think everybody knows that we're moving from an on-premises type development scenarios and more into cloud development scenarios and we've been following along on the app model for the last couple of years and launching our apps from within in SharePoint and creating provider hosted apps, SharePoint hosted apps but really another pattern is emerging along with this and this is the pattern where you have an application that's outside of SharePoint. It's just a good old web application written with web forms or MVC 5 and then what you want to do is call back in to SharePoint.

[22:58] Scot: So, we're looking at SharePoint more like it's a resource in much the same way that you would access any internet resource and how do we access that resource, use those resources in an application that maybe isn't launched from within SharePoint isn't really part of the app model and along with that we had a couple of goals. We were trying with this project to show how we could accomplish that pattern of being outside SharePoint and calling into SharePoint while still keeping the great user experience embodied in a Single-Page Application and we'll talk about some of the challenges of creating that, I'm sure as we go along. But that's basically what we're trying to do and so the scenario we used was this Research Tracker that you mentioned and the idea is that with this Research Tracker you would be able to do some research where you're collecting say, links from the internet or documents or what have you on a particular topic and as you collect them you want to be able to store that information and so we using SharePoint resources to store that information. So, basically what we're creating is a Single-Page Application that use a SharePoint lists as a backend to it and trying to create that entire thing as a SPA and then we have a couple of related apps that go along with it where we then utilize that shared—that stored information in Outlook and Word.

[24:28] Andrew: Cool. So, okay let's kind of pick this apart a little bit. So, you said that we're leveraging SharePoint as kind of like our data store and then we've build these three separate applications that are—to clarify to the listener, these are completely separate from SharePoint, they are completely independent self standing and they're not deployed from within SharePoint. So, how much stuff did we have to go through and deploy inside of SharePoint or inside of Office 365 or how much configuration has to be done to get these to work?

[25:00] Scot: Well, so the interesting part about all three of these is that there's really nothing that's required to be done inside of SharePoint itself. Our work to allow these applications the authorization to call back into SharePoint was really done in Azure Active Directory and I think that's one of the key takeaways for people is that you are able to create now these Azure Active Directory applications where your application gets registered with Azure and then in the Azure Active Directory you can also grant permissions for that to reach into other resources.

[25:35] Scot: So, we were able to register applications in Azure Active Directory and then give them rights to call into SharePoint. And this stands in contrast to the normal provider hosted app model where you actually register the app with SharePoint itself, and it's SharePoint that's keeping track of the client ID and the permission. So, really a different model but using a lot of the same ideas that you would use in a provider hosted app, but truly nothing really required inside of SharePoint to get it up and running.

[26:08] Andrew: Okay, and so if we compare and contrast kind of this idea of how most people are familiar in creating SharePoint or provider hosted applications, cloud hosted apps for SharePoint/Office 365 or these Azure apps, correct me if I'm wrong but if we do it the former way of a more SharePoint hosted app or a provider hosted app, that's going to be a little bit more of a seamless—or an easier install process for the end-users or for the administrators because they'll be able to grab these apps straight from the SharePoint store or from their catalog, their corporate catalog to really install and register this inside of the SharePoint whereas with the Azure app side, in the part that we've done in these demos for the Reference Tracker or the Research Tracker Application, there's going to be a little bit more of a manual set up although and we can probably do some command-line tools with it but it's not so much of a point-and-click install. You have to go set something up in Azure and then deploy the code to Azure and then your application can leverage this application that you've defined in azure.

[27:14] Scot: Yeah, so I don't disagree with what you're saying, I mean I would hate to paint this as overly difficult for your listeners but there is no concept of a catalog in this style of development. So, you are not going—I think what you're not going to have is you're not going to have a scenario where business users can browse available applications and then install the one they want. This is really more of a line of business or enterprise system that has involved developers and IT folks who are going to go ahead and install this application inside of Azure and grant it its permission. So, more of an installation process by your IT professionals than a browse-and-select by your business folks, I think that's the difference, but in either case I don't think there's anything overly arduous here about getting the application up into Azure. After all, even if you did a provider hosted app you'd still want to run that thing in an Azure website.

[28:14] Andrew: Yeah, okay, that's a good point, that's a good point. So, and when the app does any interaction with SharePoint, is it just treated the exact same way as we would see an app inside of SharePoint where, you know, let's take the easiest example and if the app—if the Azure application went in and created an item inside of a SharePoint list at the bottom of the page where it says created by, is it going to say the same thing we would normally see with like the SharePoint app where it says created by, name of the application on behalf of John Doe? I mean, it works the same way, it work the same way as like a traditional SharePoint app does. It's treated as an app in SharePoint, it's just defined to deploy over in Azure?

[28:55] Scot: Well, it's right. So, you'll see some of the similarities but I think the difference is where the registration and permissions are granted. So, that's in Azure Active Directory as opposed to say, going to the app new page in SharePoint and doing your registration there. But, the model—you know, the concept of the application working on behalf of the user is still there right, we're using OAuth tokens to gain authorization to get back in which is exactly the same thing that would happen if you've launch the app from within SharePoint.

[29:33] Andrew: I see, I see. So, let's talk then a little bit then about like some challenges that we ran into or some—maybe not so much challenges but if someone was doing this the very first time, they've got some things that they're going to have to figure out that they may not be familiar with. So, what are the big things here that you see that this being so different from doing a SharePoint or a provider hosted app?

[29:56] Scot: Well, so one of the nice things about doing the provider hosted apps inside of the SharePoint world is that we have reasonably mature code behind us. So for example, if you make an MVC 5 provider hosted app that's going to run inside of SharePoint Online then you can use the SharePoint context class that comes with that project template to do really most of your OAuth token management.

[30:24] Scot: So, in just a couple of lines of code you'd be able to get the access token you need in order to make the calls back into SharePoint. So, a lot of the OAuth management is really hidden from you, it's abstracted away to just a few lines of code. Now, for sure we've got some things that are approaching that level of abstraction inside of this model but I think we found that we had to get a little bit more involved with the OAuth process, the redirects that were involved, the storing of the token than we really ever had to do when we were creating provider hosted apps inside SharePoint.

[31:02] Scot: So, it is useful to understand the OAuth process, how you get a refreshed token and how that refreshed token gets the access token, how those tokens are saved and that that sort of helps you get through the architecture of this thing, whereas I think you can be a little bit more ignorant of that if you are making a simple provider hosted app inside of SharePoint.

[31:25] Andrew: Okay, so you've got—so you're going to have to go through and create—do the authentication stuff on your own, you've got to go through and deal with obtaining the token and stuff. What options then are we going to have then in terms of authentication? So—go ahead, I'm sorry.

[31:46] Scot: Yeah, it's okay. So, I think the key thing for people if they haven't done this thing before is to really understand the need to defend the OAuth token so that it doesn’t get exposed. If you're not really familiar with how OAuth works and its concepts, it's important to be familiar as you begin to move into this new style of programming but essentially the most important thing to understand about OAuth token is that there are barrier tokens and what a barrier token means is that that token is independent of the application that utilizes it. The same token can be used by any application, it's not signed for one particular application.

[32:26] Scot: So barrier tokens are often described as cash, whoever has it can spend it, right. And what that means to us as designers of these types of applications is that we have to be careful to never put the OAuth lot token in a place where it could be exposed. So, what that means in particular for the type of thing we're doing, particularly with the SPA application, is that we should not allow the OAuth token to become exposed in JavaScript or to be exposed to debugging tools that can be used in the browser. So, we don't want a JavaScript variable set to it, we don't want to bury it in code in JavaScript, any of that stuff.

[33:03] Scot: So we only want to handle those OAuth tokens on the server side and when it comes to getting a token and managing that token there's really a couple of different approaches at this point. One is to use the OAuth controller which is a special controller that you can get at GitHub that was created as a sample but basically manages the OAuth process for you and code and you can use it sort of on the outside, abstract yourself a bit away from the process but you can also get into the code and see how it's working and you can make modifications to the OAuth controller in order to manage any special cases you have.

[33:46] Scot: So, the OAuth controller gives you a lot of flexibility but requires a little bit more work on your part to get it going and then the other approach that we used is the O-365 APIs. So, the Office 365 APIs is an ongoing process, those tools are currently in preview and that ongoing process is creating more and more mature toolset but the idea is to abstract you away from the OAuth process much the same way that I was talking about how the SharePoint context does that for you in the provider hosted app.

[34:21] Scot: So, right now those give you a little bit better level of abstraction but they're a little bit more—they're more sealed, if you will, so harder to change things if you needed to change them. But the takeaway from all that is you have to have some way to authenticate with Azure Active Directory and retrieve refresh and access tokens without ever exposing them on the JavaScript side of the house while at the same time building a Single-Page Application that never wants to post back.

[34:52] Andrew: Okay, so you mentioned two different authentication options, one using some sort of an OAuth controller which we obtain with one of the Azure samples in GitHub and I'll make sure that we have references to those in the show notes.

[35:05] Scot: Yeah, put a link out there so people can check it out.

[35:07] Andrew: Yeah, will definitely do that, and then the other option is using like the Office 365 APIs and again, those are in preview mode. The tools keep getting refreshed, I believe they're up to—either update two or three about now, but we show you how to use both of those different options inside the samples.

[35:25] Andrew: Now, you touched a little bit of having to secure the access token because it's like cash or currency and we don't want this to touch the JavaScript client. I know that in all of the research you and I did, it seem like the industry was kind of split down the middle on, one camp said it's okay if it touches the client as long as everything is SSL. The other side of the camp was, you should never—the access token should never touch the client because then if the client is compromised then—or if the client is nefarious and they're trying to actually grab the token for something they can look at the JavaScript code and they can do something with it.

[36:03] Andrew: So, we took the more safe approach and just saying, the access token can't touch the server. So, can you talk a little about like what we did between how we had a Single-Page Application and then this Outlook app that runs in the client and this Word app that runs on the user's desktop? How do we keep an access token secure but then again making sure that the user was authenticated and tying their client session to this access token we were retaining on the server side for that one user?

[36:32] Scot: Yeah, okay. Yeah, so you're right about –I guess there's some debate about whether or not it's okay to expose an OAuth token. You know, we could probably do a whole other session on OAuth and its strengths and weaknesses but we definitely took the more conservative approach which I would recommend to anybody to make sure this thing never became exposed on the JavaScript side and the way that we did that was we made an MVC 5 application and inside MVC 5 server side and then produced HTML views that run on the client side and in combination with that we used a web API controller that could be called from the code that came out of the initial view.

[37:26] Scot: So, this gave us a couple different things, when the app loads it gives us a controller that run server-side prior to the HTML view being displayed. So, the approach that we took was to log in during that initial load of the application when the controller is running server-side. So look for the tokens, if they're not there redirect the user to the appropriate organizational login page, grab the tokens that are passed back to us and save them into session state all before the initial Single-Page App appears. Then once the Single-Page App appears your goal is to never have to leave that page, obviously it's a SPA right, it's the whole point.

[38:11] Scot: So, the way we accomplished that was by introducing a web API controller that could be called from the SPA. Now this works because the SPA and the web API controller are in the same project and therefore they come from the same origin and we don't violate same origin policy. So the JavaScript in the initial view the Single-Page can make as many calls as it wants to the web API controller. On the server-side web API controller has access to the same session state that the initial controller did and so it's able to retrieve the OAuth tokens from session state and make subsequent REST calls to SharePoint using that OAuth tokens. So, all of the calls to SharePoint get made on the server-side, they never get made in JavaScript. So, we've introduced this proxy, if you will, of an additional web API controller that will make all the subsequent calls to SharePoint from the server-side and that's the basic model.

[39:14] Andrew: I see, okay. And there's a little bit if UML diagram in the GitHub project that we'll reference in the show notes, but it shows how really what you are just describing, which is the Single-Page App, the Outlook add-in, the Outlook web app plug-in and the desktop Word client on task pane plug-in that are all created in this little reference implementation. None of them directly talk to Office 365 or SharePoint, the only thing that they ever talked to is this intermediary proxy ASP.NET web API—sorry, MVC 5/web API project that we've created that handles the authentication and the secure communication. They can only talk straight to that one piece. Now, we're kind of like a little custom gateway into 365 that protect the access token.

[40:05] Scot: Yeah, I would correct that just a little bit, correct that just a little bit when it comes to the Office apps. When it comes to the Office apps, remember you have a whole JavaScript library designed to allow the Office apps to interact with the Office products. So, for sure we’re using all of that, but what's happening in those cases is we're, again, executing the OAuth code prior to the app loading. So, by the time the Office app is loaded, all the OAuth stuff is already taken care of and we're just at that point interacting with the Office application itself.

[40:44] Scot: So, we still have that ability—when your listeners go and check out the things that we made, they're going to see that we have Word add-in that has gathered all the information from SharePoint on that initial load and showing it to you in the task pane and you can insert it into your document and all of that's happening through the normal Office JavaScript library, but for sure, the OAuth stuff all still happens on the server.

[41:10] Andrew: I gotcha. Well, very cool. Definitely a cool pattern here, let me ask you’re a real quick—then is there anything aside from the authentication stuff that anybody who might be interested in the Office 365 APIs? Did we leverage those in any way in the samples?

[41:30] Scot: So, when it comes to the Office 365 APIs, mostly what we did was we just leverage its authentication capabilities and the reason for that is that at this point in the preview the support for SharePoint doesn't include abstracted clients to get to everything we need. For those that are unfamiliar with the Office 365 APIs, the idea is not only to abstract OAuth but to abstract a lot of the normal REST calls you would make and just sort of turning them into methods of objects. However, at this point in the previews, the abstracted objects that Microsoft just provided us for SharePoint Online is really limited to just a few things like files and we couldn't get to the list using any kind of abstracted object so we had to fallback to making REST calls ourselves, but that's fine, you can do that with the Office 365 APIs because it will give you an OAuth token and then you can simply grab that OAuth token and make your REST calls from the server.

[42:34] Andrew: I see. That's very cool. Well, this has been really helpful. I hope that our listeners have gotten something out of this. At least, they've understand a little bit of a new pattern, an additional pattern, I should say, to their toolbox where they can build apps and not have them build more in line of business apps that don't require some special registration in SharePoint or working with the SharePoint app model, instead leveraging the app model but not having to deploy SharePoint apps and kind of have less of a SharePoint understanding in a sense and being able to work more on a—like these more Azure based or ASP.NET-based technologies and not such have a deep SharePoint understanding. Let me ask you then, where can they go—where can listeners go to get additional information about this or obtain the project and stuff and learn more about this?

[43:24] Scot: All right, well I'm sure you're going to have the links to the GitHub project which is now published and available. And also you did a video that talks a little bit more about the installation and architecture of this, so we'll have a link to that, I'm sure, at the end. And then I've been writing up some of these concepts in a little bit more detail, so you know, if this discussion went a little faster you're looking for some diagrams and some code snippets, then the best thing to do is go up to ITUnity, so itunity.com and if you look for me under the author section you'll find a series I'm working on this very pattern of creating applications in Azure that you SharePoint like a resource as opposed to launching from within SharePoint.

[44:14] Scot: So, I think those are three great places to find more about what we're talking about and I would really want to emphasize for anybody right at the end here is just that this isn't some sort of interesting academic pattern that maybe you want to fool around with. I really think that this pattern of building more classic web applications and then treating SharePoint like it's a data resource is going to be a more significant pattern that is going to emerge over the next couple of years here as one that might even be preferred over some of the things that we're doing now. So, I think this is an important thing for people to start to take a look at.

[44:55] Andrew: Very cool. Well Scot, thanks a lot for your time. I'll make sure that we have all these notes in the show notes when we publish this episode so everybody can go grab those things if they just go to the microsoftcloudshow.com website, go find this episode and you'll find all of links and stuff, the stuff that we've talked about here, so as well as information about Scot. Where can they find you, Scot, if they want to follow you or find out more information about what you're doing these days?

[45:22] Scot: Yeah, so you gave out my email at the beginning, it's scothillier.net but you can follow me on Twitter, it's simple enough, it's @ScotHillier as one word.

[45:31] Andrew: There you go. Fantastic and that's Scot with one T.

[45:34] Scot: That's right, always one T.

[45:37] Andrew: Fantastic! Well, thanks a lot of your time to today, Scot. I really do appreciate it.

[45:41] Scot: All right, Andrew. Thanks for having me.

[45:42] Andrew: There you have our discussion with Scot about these different scenarios. Now, there's two things I really want to call out here from these applications that I think is really—is a big thing and I took away from this or something that I really like about it, and you can read between the lines when I'm saying and think that I'm trying to say something negative about 365 or SharePoint and that's not the case at all. The thing that I really like about these applications is that you don't have to have really any experience at all in working with Office 365 or with SharePoint specifically as a SharePoint developer or as a 365 developer to build these applications because everything that we did was just based on REST APIs.

[46:25] Andrew: There are open REST APIs that are full documented, all we did was create lists inside of SharePoint, which to a non-SharePoint person could just be a table in the database. You just think how will create one of these things? SharePoint calls them list, somebody else calls them repository, somebody else calls them containers and that these guys calls them—or some people called them tables. That's one and the other thing is that we also had to deal with having some sort of an intermediary application and in our case, we made that an ASP.NET MVC web API application so that none of our three samples that we created, even if Single-Page Application or the Outlook web app add-in or the Microsoft Word test pane add-in. None of those talk directly to SharePoint. All of them go through a backend or an intermediary server-side application that then talks to Office 365 on our behalf and the main reason for that is because we were trying to show the best pattern that we possibly could to secure this access token.

[47:33] Andrew: We want to make sure that this access token that we got back from Office 365 was not exposed of the client. There's a lot of debate on, you know, is it okay to pass it back to the client because it's over SSL then we're good? But the only place—the only risk you have there is if the client gets compromised. But, in our case, we wouldn't say, nope, we're going to follow the other side of camp which says, access token should never touch the client and so we're going to store everything server-side and have our three different application implementations have some way to authenticate and identify themselves with that intermediary and have the intermediary store and hold that access token on our behalf so that we never see it.

[48:16] Chris: Yeah, I love the flexibility that this model gives you right, because it means that you're hiding that a bunch of that complexity from the clients and it means that you can choose how you want to talk between the client and your server application and that that is not dependent on what you can do between a client and say, Office 365, you could choose say, web API or you could do roll your own, you could choose whatever you want in that implementation and then on the backend you've hidden all of that or you've abstracted that away from the client and you can—you could do—it gives you the flexibility of doing like server-side caching, you could do all sorts of different things there right, encrypt stuff, anything you like on the backend that you're not having to worry about that from the client.

[49:00] Andrew: Yeah, yeah and all these intermediary applications they all live inside of Azure, so they all live as Azure websites, they all leverage the Azure Active Directory in the applications that we created or we defined through the web interface in Azure Active Directory and gave these application specific permissions to do things inside of 365. So, we could say that these applications are allowed to do these things as long as the users also have access to do these things. It works very much like a SharePoint on an Office 365 application already works but we didn't have to do any of the stuff inside of the 365 interface and we're able to do everything inside of Azure. So, really you could think about all the different kinds of things you could build here and have your own custom line of business applications that could really go through and take advantage of 365 without having to do any changes inside of 365.

[49:54] Chris: Yeah, no, that's nice. So, where can people find this?

[49:58] Andrew: So, you can find everything—there's the projects—we'll put a link to the blog post that your team put up on the blog.office.com site, that will be in the show notes. The code that you can grab that today, forged it, make changes to it whatever you like, submit poll request inside of the GitHub account for OfficeDev, you'll see a project called the Research Project Tracker, that's the one that Scot and I did and then we also have a video and we'll link to that as well that is a walk through. It's about 67 minutes long that I went through and explained the architecture and how everything—how we set everything up in a demo of the applications and the code as well up on Channel 9. So, all those links we'll put those in the show notes. They'll be live when the show goes live, so go grab everything from there.

[50:44] Chris: Very cool indeed. Yeah, I'll definitely be picking through it in more detail in the coming weeks.

[50:51] Andrew: Very cool. Very cool. Well, I guess that's everything that we want to touch on in this show. We didn't want to make this too long here, so let's go ahead and wrap it up and everyone gets your call actions to go take a look at this stuff, see what you think. The other thing too, hey, everyone who's listening to this show, we'd love to have conversations with you guys. Jump in to the blog, jump in to the comments for this post. They're all up on our website microsoftcloudshow.com.

[51:19] Chris: Tweet us.

[51:20] Andrew: Yeah, tweet us. Talk about it, let's have a conversation about this stuff. We want to get some more interaction with the listeners here and not just CJ and I just bouncing off. So, let's—

[51:28] Chris: Hey, I've got an idea I'm just going to throw out randomly here. Why don't we give our listener to email us a little brief on one of the projects that they're working on in the cloud and we'll take a look at the submissions and pick a couple and maybe invite people on the show or at least read them out and talk about them.

[51:52] Andrew: Let's talk about real world stuff, yeah. Exactly, let's do that.

[51:56] Chris: So, email your ideas and real world projects you're working on in the cloud whether it'd be in AWS or in Azure or Google or Rackspace or wherever and let us know on what you're working on, interesting project you're doing and we'll talk about them on the show.

[52:12] Andrew: Absolutely. Love the idea. Go to microsoftcloudshow.com, submit in that way, put them on Twitter, we'll get in touch with you. We’ll start an email dialogue and go from there.

[52:22] Chris: Sounds great!

If you have a question for us go to microsoftcloudshow.com/questions where you can submit it as .txt or record it as a .wav for an mp3 and provide a link so that we can play your question on the show. You can subscribe to us in iTunes by searching for the Microsoft Cloud Show or via [email protected] where you'll also find a full transcript and show notes of each episode. You can also find us on Facebook searching for Microsoft Cloud Show or on Twitter @mscloudshow. Thanks for listening. We'll see you next time.

[52:22] Music