Deep Dive into Salesforce Connected App – Part 3

– Hello and welcome Thank you for joining another edition of Trailhead Live today My name is Mohith Shrivastava I’m a developer Evangelist here at Salesforce Before I begin today’s session, there’s a forward-looking statement here Please do make purchasing decisions based on only the current offerings of the product Alright, before we deep dive into today’s session, I want to recap what we’ve covered in last two sessions of the CD’s on connected apps So, we covered what is connected apps We went through difference between authentication versus authorization We also looked into definition of Single Sign-on, SAML 2.0 Now, do not worry about it if you have not sort of explored Single sign-on end, because we are gonna cover this in our upcoming sessions And then I highlighted some of the connected app use cases I demoed by creating a simple connect app and we covered how to do a web server OAuth flow using the connected app And then I covered some of the secondary aspects of connected app, like how a developer can define and package and how admins can configure policies and security settings And then I highlighted some of the key considerations We also looked into JWT in the last session and we covered OAuth 2.0 JWT Bearer Flow for Server-to-server integrations And then I left you with some references Now, here we are, you know, we have connected app use cases and we are exploring some of the use cases Now the primary use case that we are focusing from our past two sessions are accessing data with API integrations and also managing access to third party apps using kind of apps So we have explored these two scenarios in our upcoming sessions We will also explore how we can integrate service providers within your Salesforce org and how we can use connected apps to provide authorizations for a service, which is hosted externally Now, if you haven’t got the recordings of the previous sessions, they are available on Trailhead live on demand videos So I have the links for them I’ll also put these links in the chat so you can watch them Alright, so let’s begin our session today So today we will continue exploring a JWT Bearer token flow for server to server integration So today I’m gonna show you how you can integrate two different Salesforce org using OAuth 2.0 JWT Bearer Flow and we will use named credentials to do that And we’ll also see how we can easily use, you know, JWT flow here And also we will explore open ID connect protocol and its usage, how it adds an authentication layer on top of Oath 2.0 and then we’ll explore how we can integrate service providers as connected apps with open ID connect So in this topic, what I’ll do is I will take a connected app and make sure that I configure that to return an ID token, and it’s gonna use open ID connect, and then I’m gonna use an OAuth provider in another org where we can, you know, just perform authentication between two Salesforce environments again, using this whole open ID connect concept And then I will leave you of course, with some references for you to explore connected apps and the functionalities that we have covered today Alright, so let’s get started Alright so in the last session, we drawled a simple apex script that did the JWT BearerTokenExchange with the connected app that we had created So we had created a connected app, and then we used this class art namespace class, which provided us with JWT subclass, and where we can provide standard claims And here the issuer is the consumer ID of the connected app And then we were able to use the certificate

from the key store So we created a certificate then uploaded to the Salesforce, key management as JKS format So using the JKS format, and then we were able to successfully sort of get an access token, you know, using the connected app that we had created Now, what I’m gonna do is today, we’re gonna take this whole apex code that we have written as sort of just use named credentials So named credentials are excellent way to redo some of our apex code And for example, you have to go through token exchange flow every time, and that functionality automatically can be handled by the named credential So what I’m gonna do is we’re gonna take two different Salesforce environments and connect them using the JWT Server-to-Server flow Because Salesforce is also a server and another org will also be a server So if you’re gonna use the connected app that we have created in one org, those sort of involved from the other org So we’re gonna invoke the rest API is from one org you know, when we have created the connected app So let me just log into the org last time where we created some of the connected apps So if we go to app manager and that’s where we had created our Trailhead Live connected app and the connected app provided us the consumer key and the consumer secret And, you know, we had a sort of also uploaded a certificate into our key store, into the certificate key management, and we have the certificate So we can use the same connected app and just, you know, log into another Salesforce environment where we can sort of authenticate, you know, using the connected app that we have So I’m gonna log into under the Salesforce environment, which is gonna make a call out to the Salesforce environment that we have here using the JWT server-to-server flow And we’re gonna use the same connected app that we have here, whether in the other environment, which is sort of a consumer in this case, the consumer environment is gonna use the named credential to sort of authenticate and authorize So let’s take a look at how we can do this So I’m gonna log into another environment and we will configure a named credential so that we can use the same credential and we don’t have to write a lot of apex code and the process of obtaining an access token and the refresh token and storing them and refreshing them All of them can be taken care of easily by the same credential So that same of the name credential It reduces a lot of your apex code You do not have to like, sort of write, the authentication flow yourself It’s all taken care off using the named credential So let’s create a named credential I’m gonna say SLforce JWT as the named credential And then my URL here would be my domain URL of this org Note that this is the org where we have created the connected app And what I want to do is use the connected app of this org and sort of configure the named credential in the other orgs and the other orgs is gonna invoke this orgs So evise org, is gonna invoke the CMPR org Okay, so let’s go to domains We’re just gonna copy paste this domain here I missed something Yes, I did miss the C here So it’s just configured that Okay, now here’s where it gets interesting So authentication type can be different types Like for example, if you are just making a call to a server, which does not have any authentication or authorization, you can just set it anonymous an Auth authentication, but let’s say that, you know, you want to authenticate with a server or with an endpoint You can use two formats that is per user That is every user in this specific org will go through the flow and that is required if you want to provide data in a specific to user context So in that scenario you can select per user But named principle is for generic Let’s say you have a single integration user AOR use just that one license to sort of invoke

and do your operations So depending on what you want, like you want per user authentication, which is sort of used always, when you want to get, you know, data specific to that context user, then you go for per user So let’s choose per user for our use case And then we’re gonna select JWT token exchange Now here is when you have all these options I’m gonna select JWT token exchange Now we need the token end point URL And we know that our token end point URL will be the odd token URL So I’m gonna configure that here And then we need the scope Let’s say the scope is full And the issuer, we need the issuer here And we know that the issuer is always the consumer key from the other org So we can also go to connected copy, here I just have it handy in my vex script And that’s one of the use cases for the named credential is you know, you don’t have to worry about storing your access token or creating a data model to store your access token or refresh token All those things are taken care automatically by Salesforce Now the audience here would be the login.salesforce.com It’s gonna be salesforce.com for sandbox, for production it’s login And then I’m gonna say token is valid for a minute And here I can pick up the Salesforce key Now how I guard this key is by actually uploading So let me show you how to sort of upload the key So what do you can do is from your org, where you have the original key, you can go to the certificate and key management, and here is where last time I created this key and then converted this key to change it’s format and uploaded it Now, what you can do is you can actually export this key So I can essentially go here and the export key store And then, sorry, I should import from key store So I say import from key store, sorry, I’m just confused between export and import here Okay, so we’re gonna export to key store here and our key store password is, let me export it So now I have the export Now, all that I’ve done here is to actually go to the certificate and key management and just say import from key store and provide the same certificate, the JKS file So basically importing the certificate between the two environments and that certificate should be seen because that’s a signing certificate for the JWT Now, one more thing we want to do is we have to start off because it is per user The subject will be per user It’s no more of that one genetic user, like last time So last time we just use one generic user here because you know, it was named principal type of integration Now in this case, you know, we want our users So that’s why, what I’m gonna do is select user that’s created a field card target username So that field essentially has the username for the other org, because we need the username of the other org to actually make the call, right? So that field I have, you know, manually sort of created the field Alright, apply it And then, you know, in this target user name field, I have the user credential that was, you know, my username for the other org Okay So now all I’m gonna do here is I’m gonna save this Okay So now we have until the Salesforce JWT sort of ready So now we can test this, you know, by making a call, you know, using apex, without having to sort of write this whole JWT call that we wrote last time So we could have lots of code here So let’s actually make a call using a simple script and we’re gonna use the same named credential and may call out to, the environment Alright, so now what I’m gonna do is write a little bit of more apex with named credentials

So instead of writing all these things, you know, using the hot.JWT class, now I’m gonna work to an apex class, which essentially will use the name credential So let’s see how we can sort of use that So, one thing we need to remember is we need to make sure that we switch the org, that we are connected to our BS code, to another org where we have created the named credential So I’m just gonna switch that so we can switch that by just going to command pallet and say SFDX authorize another org So let’s all try in another org So let’s call it as JWTClientOrg and the org where we have the connected app, let’s call it that JWTserverorg just to make our lives easier So, I mean, so that org, I have so I’m gonna just, again as I said, like with all org right here, you have to be very careful with this and say, okay, So Salesforce CLI is also using, you know, the, OAuth and, you know, by providing access, allowing the CLI to say, okay, you can access our basic information and you can also access our data via the web and you can access and manage our data on our behalf and perform requests on our behalf at any time So these are four scopes, right? So, because I know I trusted Salesforce CLI and it’s installed in my Mac machine, right? Which I only have access to it So I’m gonna say allow Right, so now I’m authorized So we are in our JWT client org Now I’m gonna write a simple script So let’s say, let’s call the, say, invoke let’s say invoke, and do more Okay, naming is hard I admit So let’s just call it as fetchExternalAccounts.apex Okay, so here is where I’ll write that HTTP code because it’s gonna use the named credential So we can get a starting template by just saying named credentialsapex Salesforce Okay So we can just copy paste it to begin with, make our life so easier And so here is where you need the named credential So we know our named credential name, so our named credential name is called SalesforceJWT So we need that, and then we need the path So our path is this right, but we need to, let’s say I’m fetching an account, right? I’m just fetching all the accounts from the org where I have the connected app So I need to make sure that I configure that URL properly So let’s see So if we go to rest API, so we’re gonna call the rest API Salesforce query So I’m gonna execute a simple rest API SOQL query So in this case, okay So I need to essentially, okay So I need /services/data/query, and then I can use my query Okay That sounds good, so we’ll just copy And we gonna do some things here So we need services/data, all of these So we gonna say services/data

equals, and then we need this query I’m just gonna put this query here from account I’m not sure how many accounts are there, so let’s see how many accounts are there here Okay, we have few, should be fine I was just worried that there are more accounts in the system Okay, so I’m gonna save this Okay, so this looks good Now notice the code, you know, the code that we wrote last time, you know, it was locked And then again, we did not, we still did not, you know, sort of code it to how to sort of store this access to open or refresh, etc But that’s where, you know, the named credentials are so powerful because all you need to provide is the named credential, and then from there, rest of the thing is sort of handled for you So here it is, so let’s see what happens now So let’s try to execute this script and see what happens so execute anonymous script Okay, so it did fail Now the error that it said is unable to complete the JWT token exchange low Okay Now let’s also change the version here, which might not be the cause of the issue, but just in case I want to change the version here Okay, so it sounds like the JWT token exchange flow itself is failing So let’s look at why it is sort of failing Let’s go once more and look at our configuration here So just refresh To go back to our named credential So we have the named credential ration So we have, let’s check everything here to make sure that we have everything sort of charactery configured We have this audience okay Interesting Let’s do this We don’t need any certificate We’re not in need of sort of certificate here The scope’s fine Okay, let’s give it a shot once more All right so, let’s actually get rid of the scope here and see if that helps Okay, so that seems to have fixed things up All right, but I’m still getting a query string has been malformed exemption So I think that’s because we need to make sure that our query is correct So, the name FROM Account So let’s fix the query and then let’s just try in securing this Select the audience What’s that? Okay, so the URI is invalid to the Call out Exception Okay, so that means, again, our queries are not perfect

I think what we need to make sure is we need to make sure that this is the queries The queries are valid, or they’re properly formatted So, okay So what we had there was really correct So what we required was to change the query I think, I need to stroke this, this makes a lot of sense So I think that was a typos so let’s get one more shot here Okay, this time it went fine and successful We are still getting the invalid query locator We are getting invalid query located here So let’s go back to the documentation here We’re gonna go back to rest API Salesforce example So we are working with queries So we wanna find out what is the mistake that we are doing here Okay We had a typo once more four So this is the right syntax where the URL should have this then we select, Select from account Okay, now it seems fine So let’s just give a shot here Okay This time it did go through and we see this lovely output here Okay, so it seems all the accounts are coming up So as you can see, you know, notice the amount of code that was required to sort of make this call using named credential It was pretty small and you can really call any API, including tooling API, or other APIs like metadata API, by using this code So it’s just like fine lines of code Obviously you will have to handle the error and other things, but this is what it is So all you need is a certificate So you can basically distribute the certificates to your consumers of the connected app And then all you need is they will have to go and upload it into their certificate and key management And once they do that, you know, the next step is pretty simple All that they need to do after that is create a named credential, which you can also package, but, you know, the URLs, might change So it would be good to create a directory in the consumer environment So all you need is the name of the credential So all you need is the name of the the named credential And from there, you know, you should be able to use the same name and then make any API calls So that concludes, you know, how to work with JWT and you know, how to use named credential to simplify the JWT Bear Token Flow All right, so let’s look at what is open ID connect So, you know that OAuth 2.0 is a framework for authorizing applications and it is not designed for authenticating users to application So that’s where an openID adds value So open ID connect protocol sort of gives an identity service on top of, or to allow, you know, your authorization servers to authenticate users for application and return results in a standard way So essentially it’s just a one more layer on top of OAuth 2.0 So that handles the authentication for you So note that what was, you know, designed for authorizing it’s not designed for actual authentication and that’s where open ID connect is so popular So that’s where open ID connect is so popular because it adds that capability All right, so connected app also provides us that capability that you can configure the connected app to sort of use the connect app

as you know, open ID connect So Salesforce can be an open ID provider itself, or there are capabilities in which, you know, if there is any server that sort of has open ID implementation, Salesforce can use that as an authentication provider or we call it as OAuth providers So to explore that, let’s actually go to our connected app and, you know, configure our connected app to, you know, use this as open ID So first thing you will see is there is OAuth scope called open ID, which allows access to a unique identifier So we need to make sure that our connected app allows for that unique identifier So you can pass in that open ID scope, had written an ID token, and we will see that in a short while So we can also configure the ID token and, you know, make sure that it includes the standard claims So this would be a JWT token The ID token itself will be a JWT token and that will, you know, if you say go standard claims it will include things like end users, name, profile, phone number and address Now, you might also define custom permissions and custom attributes So custom permissions are permission You know, it’s like if your application requires a permission check, you can create these custom permissions so that you can use them in your application code So you can actually include that as well and you can also include customer attributes, like for example, your connected app uses some custom attribute and you want to read those attributes and perform some logic So you can include those custom attributes as well So for this case, I’m just gonna say, you know, include the standard claims And then we also have ID token audiences So this, you specify the target service, you know, where you want to use this ID token For example, you know, you can use this ID token for login.salesforce.com That is if we want to use this connected app as you know, as a provider, as an OAuth provider So I can have another org like the org that we took in our previous samples, we can use that org and use this specific connected app to sort of configure that, you know, authorization behavior or sorry, the authentication behavior, okay? So in this example, what I’m gonna do is I’m gonna just say, okay, I’m gonna use this for log in I’m gonna use this from the login.saleforce.com So any other URLs that you want to use, you can say, enter and enter the URL, okay? So again, just to reiterate things here, connected apps, you know, provide you the capability to use the open ID connect, and the way you do that is by configuring an ID token So you select the check box and then you choose what claims that you want in that ID token So apart from access tokens and refresh token, an ID token will also be issued that will have the standard claims, and you can use that So it will give you a unique identifier and you can use that unique identifier in your external application for different logic or different purposes here, okay? So now I’m gonna save this, I’m gonna save this Now, it’s gonna take some time It says two to 10 minutes for us, for the change to be effective so that we can actually play with this and see how the ID token looks like etc, okay? We’ll come back to that, but before that, let’s try to understand how, you know, this whole entire flow works That is, you know, the ID token specific flow works So basically it’s part of, you know, the OAuth flow itself So, you know, you can request an ID token by specifying the scope, which is open ID scope, and that will return an ID token but let’s look at diagrammatically how this works, okay? So I have a lucid chart when I’m gonna draw some diagrams here So we have a browser, right? So, first we have user, okay? so user uses a browser So the browser that user is gonna interact is interacting with an application So let’s draw an application here We have an application that uses sort of interacts through the browser Okay And what happens is, you know, when the users are trying to authorize for the first time, we need, so we have a stack here, that’s sitting on the cloud, obviously

So we have a stack and we have two specific things here So we have, you know, this already, right? So we have authorization server that sort of handles OAuth for us And then I also have a resource server in Salesforce, right? So resource server is gonna have the API and the other resources for an authorization servers Can be accessed using the it’s specifically meant for authorization and authentication So we have resource server right? So what happens is, let’s just put it down here like this So really what happens in this process is the browser, right? So it’s gonna go ask for authorization And then once the users are approved, the authorization, you will see that once users sort of does their authorization part, So once the user sort of authorizes it, right? So you will see that an org token, right? Is sort of retreat So, you know, it basically authorizes and you get an OAuth access token, right? Plus you also get an ID token, if, you know, open ID is sort of configured for the connected app And then with the access token, you can really sort of start requesting for information from the resource server So you’re passing the access token as a header, and you start like the resource servers start sort of responding to the application So that’s how this entire thing works So the key thing to note is, you know, it would be an authorization server, which will have, you know, and the thing about the resource server one thing I forgot here is the resource server also has an end point for getting the user info Like, for example, if you need to request more information about the user, it will have another end point The end point might be, something like /user info that you can call with the access token and get the user information, okay? So that’s how this entire flow sort of works, pretty simple You know, it’s just OAuth protocol It works very similar to OAuth protocol, except that you would see that open ID sort of adds that authentication there And also, you know, it’ll give you an endpoint, quite user info that you can sort of use the access to open and receive information about the logged in user and the ID token, essentially it’ll be a JWT token, and that will have, you know, more details, like for example, it’ll have all the standard claims you can add some custom claims as well All those information can be retrieved from the ID token Okay All right, so now let’s actually see this as an action So let’s see Okay, so there is a Heroku application that we can use to play with it It’s called Heroku OpenID SSO Salesforce sample lab That is one application that we can use Yeah, it’s called openIDconnect@heroku.com So let’s try to use our connected application So hopefully the effect has taken place And if it has, we can just use a login as our host So client ID is the consumer key We need the client secret I’m gonna reveal and copy and sort of paste it again Client secret has to be protected in your application So whenever you are sort of, treat clients secret as your password So make sure that our strict, you know securities, you can encrypt it and store it always in the database, never expose it to the front end application and yeah Make sure that you encrypt and store it Okay, so now hopefully this application, right Once it sort of configured, and it can go through this flow, so let’s try to go through the flow

Okay, so redirect your, must match Okay. So here’s another thing, right? So when you get this error that means, you know, our redirect URI is not configured properly, okay So we have to come back and make sure that our redirect URI is configured Now you can also specify multiple callback URLs by just doing an enter here and, you know, using the URLs in new line So you can always do that Okay, now it’s gonna take, again to do eight to 10 minutes for this to be sort of available for us to actually play with it All right, so now let’s look at, you know, how we can integrate, you know, any service providers as connected app, but open ID connect So we’ll start with, you know, exploring this concept with, two Salesforce environment I’ll have, you know, I’ll use the same connected app that we have used here to sort of, you know, make sure that we configure that as an ID token or as an open ID provider, and then I’ll have another Salesforce environment sort of configured so that, you know, we can directly invoke, you know, our directly authenticate with, you know, with this specific org So let’s see how we can do that So I’m gonna open another environment where we will work through So we will go through this So let’s bring up the environment that we used previously So I’m gonna go back here Alright, so now I’m gonna set up an Auth provider So let’s set up an Auth provider here Let’s use an Auth provider So our authorization provider, so Salesforce provides all of these authorization providers Again, a lot of them have implemented open IDs So, you know, that’s how we are using open ID But if I have a specific provider that sort of uses an open ID, you can do that Now, if somebody has an OAuth and did not have, you know, open ID, we give you a service that, we give you an apex interface that you can implement, or a service that provides, you know, OAuth so that we can do open ID connect with that as well For timing, we’re gonna explore with another Salesforce environment So let’s call it as, you know, Salesforce server Let’s name it as Salesforce server So it requires, again, the consumer key, the consumer secret all of these information So I’m gonna keep it from one Salesforce environment and it requires the secret Here’s the secret And then these URs are automatically filled the default scopes Now this is where if you are using open ID, you can specify it as open ID And then, you know, you can also blank it out and say full API, depending on, you know, the tokens or those scopes that you will have access to We can leave all of these as blanks for timing and save Then notice what happens when you save We got certain things like we got OAuth only initialization URL, and then we have existing user link URL Then we have callback URL, we have singles log out URL Also, if you have communities in your OAuth logs so give the same set of URLs for communities, because one of the things you can do is actually use this open ID with community as well Let’s actually use these Auth provider to sort of see if we can establish an authentication with the Salesforce server or the other Salesforce server Now, before that actually let’s play with this application, the head of the application that I was talking about So let’s actually go to the open ID flow so that we understand this whole flow So we say next, it will take you to an org that it’ll ask you to log in So again, you know, what is very important to note is you have to be careful around what you are, sort of allowing the access, right? So in this case, so my connector app has a full scope

So that’s where it included all of these and the connected app that is being used here is this one Now, if I say, it’s not me, it will take me to a log in URL where I can let’s log out, you know, just a wide, the conclusions here Let me log out Note that we are using the connected app of this environment and we will, okay so make sure that we have the right consumer key here Then we have the right client secret next, Okay It takes you to a URL that asked for authorization So I’m gonna say login it, it logged me in and notice what happened So this application sort of made a get call So initially it just did an OAuth it’s just an OAuth with client ID in the URL and the redirect URI and the scope as the open ID connect, sorry, this is a callback URL And the response type is code because we are going to the authorization flow That’s authorization flow So after this, right So we can actually make another request this time, you know, with this authorization code, so let’s do that Now, notice this So here, the request was made with grant type authorization code the code value regard from the previous step And then we also had client ID, client secret redirect URI What else was there? And then there was the redirect URL Okay, so this also give us an ID token, okay? And the ID token, once it’s sort of decoded, it should see that it has all the claims that we asked for like address, email, names, you know, the profile pictures and zone information, all of these details Okay. So now that we have fetch, the ID token, right? We can also call the user in for URL So that’s the next step So here, as you can see, we can call the user in for URL with the authorization token And this will return us all the responses about that specific user, where the user ID, the organization ID, all the URLs that we need for different APIs, and then, you know, the language and the user type and all of these information So that’s how the open ID sort of works Now, let’s go back and try to cover the last scenario where we were trying to sort of, we have configured an OAuth provider in another environment using the connected app that we have built in this environment So let’s try to essentially see how we can sort of use this in an apex and see how this thing works So it’s pretty simple from that point So we go to that Auth provider, let’s go back to that Auth provider here So in the Auth provider, so notice all these things Then now what I’m gonna do here is we will use the named credential So let’s create a named credential, like we did last time Instead of calling Salesforce JWT, I’ll say Salesforce OpenID Okay And it’s gonna ask for the URL, it’s gonna be same The URL is gonna be same that you can get from your domain URL It has to be the domain To copy this URL Well, this time, what we’re gonna do is we’re gonna say, should we say per user, okay, we’re gonna say per user, per user, at this time, I’m gonna select OAuth 2.0 I’m not gonna select JWT token exchange And notice what, when I select OAuth 2.0

I get to choose the authorization provider and I know it’s Salesforce right? Now, it asks for the scope The scope can be again, API full, if we need the ID token, it can be open ID scope And we can start the authentication flow on safe That’s if you wanted to play with it Then what’s happening here So again, we have the redirect URI mismatch Okay, and that is actually expected because you know, it’s actually going to the redirect URI specified as logging.salesforce.com/services/OAuth 2.0 So that should be also added to the redirect URI So let’s come back to making sure that the redirect URI matches actually So we have to go back to the connected app So we’ll go back to app manager and make that change and come back here Let’s just start the redirect URI where it’s supposed to go So it did go with a Spanish type code client Okay Alright So let’s see if there is any documentation help here So setting Salesforce as Auth provider for another Salesforce environment I believe the callback URL looks good I just need to add HTTPS and hopefully this is all we need So let me save this It’s gonna take some more time for the change to be effective Okay, so we were looking into the Auth provider Okay, so I’m logged in So let’s do this So let’s go back to our new credential I’m doing the authorization flow So let’s just change this to authorization Okay, the change this means that the changes are changes not propagated in so we’ll have to wait for some time Or have I not configured the redirect URL? Let’s check it back Okay, so let’s come back here Let’s go to the Auth provider once more to see if there’s any thing that we are missing in the Auth provider

So do we have a redirect URL here Okay, let’s actually look into the OAuth only authorization URL and see what happens here As the same issue, it says redirect URI must match configuration Yeah, interesting Okay, there it is So I think the call back URL is this one And I think we need the call back URL specified there in the connected app here So let’s just go and fix that Okay, so we need to make sure that this is our callback URL Okay, It’s fine It’s gonna take some time It’s an asynchronous action So it’s gonna take some time to update to this URL Let’s hope that change is propagated Alright, so let’s give a shot this time Let’s, try once more now with our named credential I think that was our issue So just to be clear, the issue was, you know, we get the call back URL, when we created the Auth provider and our connected app, the original connected app should use the same URL So this method is little bit, you know, confusing than the JWT methods that I showed you, because that was you know, you just need the keys, you just need the certificates And it just works That’s the server to server authentication But if you really need to go through an OAuth flow an authorization flow for every user, then you know, it’s always best to use the specific flow Okay, so let’s get back to the connected, sorry, not the connected app So we’re gonna go to the Auth provider So we’re gonna go to the named credential that we have Let’s go back to our named credential and let’s make so the open ID one And let’s just save it and see what happens now Okay, so there it is Now we did not get that error So that looks good So now all we need to do here at this point is to sort of authenticate it with your user credentials So this is the other org, choose a credential Just keyed in my credentials here It looks like the credentials were out So we couldn’t authorize because of an OAuth error The generic error an unexpected error has occurred during authentication Okay, so it says that the requested scope is not allowed So that means, so look at how the errors come The errors come on the top on the URL It says an invalid scope and the requested scope is not allowed So that means I was using one of the scopes that was not allowed So let’s come back and fix that So let’s come back and let’s fix the thing So let’s look at, so I need you to log into that environment once again So first let’s see what scopes do these connected app has So this has this, the full scope and the refresh and the open ID Okay So I think I used a scope, which I should not have So let’s come back, come back to the org It’s good that I’m making all these mistakes, because that way I can go through the errors with you, with our dear viewers So, you know, that way we know that, okay, these are the mistakes that one could do Ultimately I wanna make sure that the same scope is sort of provided in the Auth provider So I’m gonna look into the Auth provider as well and make sure we have proper scopes here

Yes, we have the right scopes here Okay So I’m gonna go through the flow, gonna go in and ask me for the credential I’m gonna key in The requested scope is not allowed Okay Let’s just fix the scope again Maybe I just need to not go through the OAuth flow and just save this first Okay so now it saved and it has only full and open ID So now I will try to go through the workflow I do need to select that checkbox of the Auth flow Hey, we’re still getting this error The requested scope is not allowed Okay, let’s get rid off maybe one of the scopes Let’s get rid off, Open ID Let’s see Just, okay, that was it Okay, there you go So the authentication did not provide a refresh token because in this scope we did not provide that So we can provide the refresh token scope as well So let’s see As you can see, we cannot go through the open ID flow, you know, by this means, okay So in the scope let’s provide the refresh tokens and offline access and see what happens I’m gonna say, okay, the scope contains a character that is not allowed Maybe I just need to restrict it has to be refreshed We have to be very, very careful with basis here and the characters, okay? Let’s see Yeah Quite let’s just get rid of the offline access and just use refresh token All right, so now we are not getting that warning anymore Okay, so now I should be able to use this, you know, to make calls So let’s see So all that I need to do is replace So now I should be able to replace this with this, and this call should go through because I’m authenticated So I’m gonna go here and say, execute, getting an error here You don’t have permission to view the data Okay, so I do not have permission to view this data Okay, that is because I might really not have, I’d have to configure some permissions So let’s see what those permissions are So one of the things we need to do when we are, is making sure that our users, like for my example, my user, has that external apps sort of added, so authentication settings for external systems, but this is where what I need to do is make sure that I provide the open ID and it’d be OAuth 2.0 and the user would be my user So we need to make sure that this happens Okay, so it’s still pending But if I go to my personal settings and if I go to authentication settings, this is where Okay now it says, I’m authenticated I’ll also see myself here, okay Let’s execute it now

Okay Now the call is successful It says the session has expired That’s because, you know, I did not go through the flow So let’s fix that So we have to go through the flow So now I’ve gone through the flow and now I should be able to make the call Okay So this time I can see the data and there are 12 across that already done Okay So that’s how you, you know, we can configure an Auth provider and use named credential to sort of connect to any system which has open ID And I took an example of two Salesforce environment that I’m just using So one Salesforce environment has a connected app and we have used that connected app, you know, to act as an authorization and authentication settings for other Salesforce environment Okay So there we have, we met our objectives for today’s session So we integrated two Salesforce org using OAuth 2.0 JWT bearer token flow This was pretty easy, you know, with the JKS certificate and with the named credential And then we looked into open ID protocol and you know, how it adds that authentication layer on top of OAuth layer And then we also explored, you know, how we can integrate you know, a service provider as connected app with the open ID connect So we created a connect app We enabled it for an ID token And then we just configured that as an authorization provider and none of those Salesforce environment then use named credentials to sort of, you know, access the data and the sessions Finally, I have a slide on references I’ve included the documentation, which I read on Auth provider And you know, it has all other references for you, some Trailhead modules as well Finally, I wanna take some time and thank you Thank you so much for viewing this session And if you have any feedback do reach out to me via my Twitter handle and see you next time Thank you