Play by Play is a series in which top technologists work through a problem in real time, unrehearsed, and unscripted. In this course, Play by Play: Authenticating External App and Service Integrations with Salesforce, Chuck Liddell and Don Robins demonstrate how to choose from the many options available for securing external app and service integrations with Salesforce. Learn an overview of TLS and HTTP network mechanics, Apex callouts using Named Credentials to cleanly separate code from authentication configuration, OAuth and common Salesforce OAuth flows, and authenticating inbound calls to various Salesforce APIs using both SOAP and REST. By the end of this course, you’ll have gained deep and valuable insight into the flexible and powerful authentication mechanisms available for both inbound and outbound Salesforce integrations.
Don Robins is a well known Salesforce MVP, instructor, author, and speaker.
A custom business application developer for more decades than he cares to
admit, he focuses on Salesforce technical instruction and knowledge
Course Overview (Music) Welcome to this Salesforce Play by Play with Pluralsight. Salesforce Play by Play is an interactive series where we sit down with Salesforce experts, such as MVPs, consultants, developers, and architects, to discuss common challenges faced every day by Salesforce customers. We'll be learning while discussing concepts and debating tradeoffs on various approaches to solving real-world problems. We learn by reviewing system configurations or writing code, and then exploring the benefits of any particular solution. In this course, we challenge Chuck Liddell, technical architect and community leader, to help us understand how to choose from the many options available for securing external app and service integrations with Salesforce. First, Chuck sets the context and shapes our conversation around authorization versus authentication. He provides an overview of TLS and HTTP network mechanics, and using analogy simplifies the complexity of OAUTH and its basic flows. Then he takes us into a discussion of outbound integrations initiated from Salesforce, and the power and flexibility of named credentials, a declarative low-code security mechanism. He shows us Apex callouts using named credentials to cleanly separate code from authentication configuration, and demonstrates both password and OAuth callouts, introducing auth providers and showing how they complement named credentials. Chuck then takes us on a deep dive into custom auth provider implementations, and how developers can build their own using Apex code. We change direction, and Chuck dissects the various use cases for inbound calls to Salesforce, exploring how service and app integrations depend on a Salesforce feature called the connected app. Along the way, he demonstrates authenticating inbound calls to various Salesforce APIs using both SOAP and REST, shows us some freely available developer tools, and demystifies the different kinds of tokens used in authentication processes. By the time we're done, you'll have gained some deep and valuable insight into the flexible and powerful authentication mechanisms available for both inbound and outbound Salesforce integrations, and you'll have a solid understanding of how to best configure your own application and service integrations with your Salesforce org. So, please join us for Authenticating External App and Service Integrations with Salesforce.
Calling out from Salesforce: Out of the Box So let's look at outbound from Salesforce, and when I say outbound from Salesforce I mean a communication that begins from the Salesforce side. I want to make it clear that sometimes you're going to call into Salesforce and pull data out. That's not what I'm talking about when I'm talking about outbound. I'm talking about who starts the call. Right, so that would be an inbound call, that calls into Salesforce and pulls it out. And if you're thinking about the data movement level, where does the data start and where did it end up, it'd be like from Salesforce or somewhere else, sort of outbound, but specifically we're going to focus here very clearly on the beginning of the communication, so who initiates the communication. So when we talk about initiating communication from Salesforce, we have four primary options. We have the ability to send an outbound message, which is a SOAP-based message, it's been around for a long time and focuses on sort of data change, so which S objects have been modified, and what are the new properties. We have platform events, which I'm mentioning because I can sort of drop of a platform event from Salesforce, and then someone else can potentially pick it up. It's not quite the same, but I am initiating it from Salesforce, so I'm including it on my list. I have my Apex callouts, which is using Apex code to initiate an HTTP communication with an outside group. And then finally I have the ability to write to an external data source using Salesforce Connect, so in an external data object there's actually a bidirectional flavor of that. I'm including it on the list because it's technically possible, but the first three are free, and this one is a paid feature, and also it's a little bit complex. Really, of the ones that I mentioned, the Apex callouts are the ones that will be used most heavily by most people, so I'm going to focus on those today.
Summary and Recap Let's recap, because there is so much. We went deep today. We went really deep today, but we needed to go deep on this topic. I've been wanting to do this topic for quite a while, because you can find the pieces of this sort of scattered all over the place, but it's really hard to get sort of a comprehensive overview of everything that's available. So let's talk about, just very high level, go back and revisit, what were the aspects that we covered, and you know, just anything else that you might want to add. Sure, so really we were talking about securing information, right, and we talked about securing information in motion, so that was our TLS discussion, our secure connection. We talked about using public key cryptography, so certificates that validate the identity of the the service we are talking to. And then we were talking about inbound versus outbound, right? In outbound we said we had a few different things we could do, but we focused on named credentials and Apex callouts using OAuth, and then on the inbound side we looked at both OAuth and sort of traditional SOAP WSDL login, but saw that they were fairly interchangeable once we had a session ID. On the outbound, just a friendly amendment, we also talked about auth providers, and you showed custom auth providers, which I thought was really cool, and how you could hack the named credentials. Really kind of bend those to get them to do what we need to do, because OAuth is a framework, it's a guideline, it leaves a lot of room for interpretation and many different implementations of it exist out there. So there's no one size to fit them all when it comes to OAuth, and Salesforce offers some stuff out-of-the-box, but they can't accommodate every different permutation that's out there. So there are pretty great tools, we talked about there are some awesome levels of abstraction in there that are convenient for users and developers and admins, but also more secure because things are separated out, and we can use those tools to get at what we need, which is to actually get some information to connect between two things. At the end of the day, that's the goal, so that's sort of where we focused.