Name: Setting up SAP Concur OAuth2 Authentication in SAP Concur
Uploaded: 2024-4-17
Duration: 554 s
Description: Learn how to develop SAP Conquer extension solutions and authenticate using APIs in this informative video. Get insights on creating company request tokens, refresh and bearer tokens, and accessing the API.# This description was auto-generated #

Share feedback

<p>We are aware of intermittent issues in accessing the learning content</p>

We are aware of intermittent issues in accessing the learning content

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

Please try again later

Sorry, we encountered an error

Try again or reset results to continue browsing

We didn’t find what you’re looking for

To continue, please log in

Your session has timed out

Explore {title} at SAP Learning. Find out more!

Enhance your learning experience for free

<div><div><div><div><div>Learn how to develop SAP Conquer extension solutions and authenticate using APIs in this informative video. Get insights on creating company request tokens, refresh and bearer tokens, and accessing the API.<br><br># This description was auto-generated #</div></div></div></div></div>

Setting up SAP Concur OAuth2 Authentication in SAP Concur

Welcome to the SAP HANA Academy. My name is Bob and in this playlist we will be looking at developing SAP Concur extension solutions. In this mini video series we will be looking at an overview and how we authenticate when we are using the APIs. In this third video we'll be looking at creating company request tokens as well as looking at how we create our refresh and bearer tokens. In the previous video we looked at logging into our sandbox and we looked at creating an application within our authentication admin panel within application management here. So we built the application which has a series of scopes and grants. This is all the list of scopes and grants that I'm going to use which give us access ultimately to our APIs. And when we create the application, you'll see at the top we don't really have an app ID because the client ID is actually the same as the app ID. In terms of the password or the client secret, we've already looked at creating it but it of course can be regenerated here. Now for demo purposes, we'll be using a working example that I've already created. All the steps I'm going to perform are actually really well documented. I'll put the URL here at developer.concur.com/ api-reference. So these steps are actually what we're going to cover in the next in this video and accessing the API as we'll look at in the next video. So in terms of getting our refresh token and our bearer token, you can of course read the documentation or of course you can just watch the next five minutes of this video. Now all the APIs I've already actually imported into a workspace in Postman. You should see a link in the description of the video in order for you to access these APIs. So we're going to focus in this video on OAuth authentication and you'll see that there are two steps. Getting the refresh token which lasts for around six months and then we'll get what's called an access or bearer token. We don't have any parameters or authorisation here and for our headers we're only specifying one content type which is a form which will come from the body of the post. You'll see we have six keys. We've obviously got our client ID and our client secret which we've already discussed. The client ID will also act as the application ID as well. You'll also see that we've got this thing called grant type which is password and then we've ultimately got a username and password. Now this username and password is nothing more than a company token. It's essentially a UUID company password and login. And for partners who don't have admin rights on their sandbox they'll get these credentials from their deep link which we'll discuss at the end of the video series. As we have admin access I'll show you how we can access them. So back in our sandbox if I go to authentication administration you'll see we've got another panel which is company request token and this will be used to generate a request token to obtain what's called a company JWT. So if we select it what we'll need to do as an input to this page is we'll have to provide the app ID or essentially the client ID. So I've already put that in my postman collection. But of course you can obtain that as well from your application management tab as well. But I'll grab it from Postman and I'll paste it here because it's the same thing and I'll click submit. What you'll be presented then is with the company UUID and the company request token which of course is kind of like the password. Again I've already placed that company UUID you can see that it ends with 3B62. It's a good idea to copy this and put it into notepad somewhere so you've got it. You'll also see here that it says to obtain that JWT you have to use the password grant with the new token and the company UUID within 24 hours in our case. So what I'll do is I'll go back, here you can see we've got the grant type password and you've got the username which again ends with 3B2 and then all I need to do ultimately paste in that password here where we've got Company Request Token I'll copy it from my company token page and back in Postman I'll paste it here as my password like so. The only last piece we have to add is a key code credential type or cred type and call it auth token as well. That is because we're going to be getting a request token and ultimately a bearer token. Nothing else to add. I've added some tests but you don't really need to see what we're doing in those tests. We'll just send that post and at the bottom you can see the response. So there are some valuable pieces of information here. One of them is you can see that we've got a bearer token and the value of the bearer token is within access token. So you're probably thinking why don't we just use this access token? Well you should note that although it might be tempting to use this bearer token immediately, You'll only have five times to retrieve the refresh token through this connect using a password grant within any 24-hour period. So the problem is that if you repeatedly use the bearer token with this password grant, you'll not be able to use the application for 24 hours. So you would have to keep generating that again and again. You'll also see that you've got the scopes that we're applying this to. The type of token and the value of the token as well. Now what we're looking for here is the actual refresh token. So if I scroll down you can see my refresh token as well as when it will expire. And also what's called the geolocation which is essentially the location of your data center which you're using. Now this is the refresh token that we're going to want to use. And we'll be using the same refresh token again and again in order to get the bearer tokens that we'll need in order to use the APIs. Now the question you're probably thinking is how long does that refresh token last? Well we can see that indicated here within the key refresh expires in and then you've got this number. This number is actually a Unix timestamp and it should last for around, the token should last for around six months. But if you're ever unsure, all you'll need to do is go to an epoch time converter, there's loads of them available on the web, and then all you'll need to do is paste in that time that we've copied from Postman, and then we'll translate that to a human date. So you can see here it's in six months, but of course you can also check when that refresh token will expire any time you want. So now we can actually go and get our bearer or access token, which is the second step. So we'll copy this refresh token and what we'll do is we'll launch that second post where we get that bearer token, it's also called an access token. You see that we've got very few headers apart from the form which is of course enclosed within the body. Again we've got the client ID and the secret. The grant type this time though is refresh token and this is where we have to place in our refresh token. So I'll paste it in here and then all we need to do is perform a send. So as you can imagine, you only need to refresh the refresh token once every five or six months. But the bearer token, you'll have to refresh every hour when you're actually using it within the APIs. So if I scroll down, you can see we've got the same information that we had before. But what we're looking for here is our bearer token. And here you can see you've got the time it expires, the token type, but ultimately what we need is the value of the access token. Here we can see the refresh token that we used and when it expired. But again, this access token here under the word bearer is what we're going to use when we're calling the APIs. So what I'll do is I'll copy that bearer token value, which is within access token. And in the next video, what we're going to be doing is creating a user. So we're going to be performing a post to SAP Concur. And then we'll retrieve that user's details just to test that we're able to successfully authenticate when using bearer tokens when you're using the APIs which connect to SAP Concur.