Exchange JWT token from Azure with token issued by SAP Cloud Identity Authentication Service

[harjeetjudge]

As a developer you may have the need to authenticate to applications hosted in SAP Business Technology Platform (SAP BTP) from 3rd party apps.  This can be accomplished using the JWT Bearer Token exchange in SAP Cloud Identity Services (IAS).  In this blog I will showcase how a JWT token from MS Azure can be exchanged with token issued by IAS.  The IAS token can be used to get an access token from SAP BTP to authenticate to SAP BTP applications.  The picture below highlights the high level workflow to achieve this goal.

Step 1 of the process involves making a request to Microsoft Azure application using either Resource Owner Password Credentials or Authorization Code flow.  The end result of this process is that Azure AD will issue an ID token which we can use for token exchange.  Few things to note for this to work:

1. SAP Cloud Identity Authentication Service should be setup as an OIDC application in Microsoft Azure.  This can be accomplished using this blog.


2. Update the manifest file for Azure app to make sure accesstokenAcceptedVersion is set to 2.


3. Use the right token endpoint for Microsoft when making the token request from your client.  It should be https://login.microsoftonline.com/{{tenantID}}/oauth2/v2.0/token.  Make sure to retrieve the v2 of the token.


4. ClientID used in the request should be for the SAP Cloud Identity Services application registered in MS Azure.

Here is screenshot of the request to MS Azure using Postman and retrieved token from Azure.

Decoding the ID token shows that the aud field is set to the clientID of the IAS application in Azure.  Note that the token version is also set to 2.0.  Both of these are necessary for SAP Cloud Identity Authentication Service to accept this token for a token exchange.

In Step 3, the Azure token can be exchanged for a token issued by IAS.  To successfully do this exchange we need make sure that the issuer of the external corporate identity provider is configured as a corporate identity provider and set as a default identity provider or configured via Authentication Rules (Conditional Authentication) in the administration console for SAP Cloud Identity Services.  In addition Client ID and Client Secret are also required to send the request.

To retrieve the information required for token exchange, follow the steps below:

1. Access SAP Cloud Identity Authentication Service admin console using the URL: https://<iashostname>.accounts.ondemand.com/admin.


2. Authenticate as an administrator user.


3. Click Applications & Resources >> Applications and select your application.  In my case I am selecting the app created when trust is established between BTP subaccount and IAS.


4. Scroll down and click Conditional Authentication.


5. Confirm that Azure is setup as the Default Identity Provider for your application.  Alternatively, it's possible to leave the Default Identity Provider to Identity Authentication and set conditional rules to forward the request to Azure.  For more information on setting up conditional rules, follow the help guide.


6. Click the back arrow and click Client Authentication.


7. Under Secrets, click +Add to add a new secret and click Save.


8. Make note of the Client ID and Client Secret as that's required for API authentication and click OK.

 

We can now send the request to IAS for the token exchange.  The request should be formulated using the following information:

• Token URL: https://<iashostname>.accounts.ondemand.com/oauth2/token


• Request Headers:
  
  
  
  • Content-Type: application/x-www-form-urlencoded
  
  
  • Authentication: Basic Authentication
  
  
  
  


• Body:
  
  
  
  • assertion: <id token from retrieved from Azure in the previous request>
  
  
  • grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
  
  
  • client_id: <client id from IAS>
  
  
  • client_secret: <client secret from IAS>
  
  
  
  

See screenshot below of sample request and the response from IAS.

Decoding the token, we can see that issuer is set to SAP Cloud Identity Authentication Service tenant.  We were able to successfully exchange the token from Azure with one issued by IAS.  The attributes you get back in the token will depend upon whether the user record exists in IAS or not.  In my case my user also exists in IAS so I see attributes like user_uuid which are available in IAS user profile.  If the user record doesn't exist in IAS(pure proxy scenario) the token will be rather basic as shown in my second screenshot below.

Token if the user doesn't exist in IAS.

As a final step, it's now possible to authenticate to BTP using the token we received from IAS.  This is only possible if the BTP subaccount has an OIDC trust setup with IAS.  The process will create an application in IAS that should be configured using the steps listed earlier in the blog.

To formulate the authentication request to SAP BTP, we need to perform the following steps:

1. Log into BTP Cockpit and create an instance of Authorization and Trust Management Service using the apiaccess plan in your subaccount.


2. Click the service to see it's details and click Create to create a new service key.


3. Provide a name for the key and click create.


4. Click on the generated key and make note of the clientid, clientsecret and url fields.

We can now send the request to BTP for authentication.  The request should be formulated using the following information:

• Token URL: <url field from key>/oauth2/token


• Request Headers:
  
  
  
  • Content-Type: application/x-www-form-urlencoded
  
  
  
  


• Body:
  
  
  
  • assertion: <id token from retrieved from IAS in previous request>
  
  
  • grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer
  
  
  • client_id: <client id copied earlier>
  
  
  • client_secret: <client secret copied earlier>
  
  
  
  

See screenshot below of sample request and the response from SAP BTP.

This token can be used to access BTP services within that subaccount.  Let's decode the access token to see what information we get back.

Feedback and comments are welcomed.

[gregorw]

Hello,

thank you for this great overview post about the OAuth Token Exchange. But I have some questions regarding the step where you create an xsuaa instance with plan apiaccess and the corresponding service key to be used for exchanging the IAS token to a XSUAA token:

1. Why do you use the apiaccess plan? With the created service key you could also get directly a token that can be used to create and update users in the subaccount. I think this is not intended. You better would create a xsuaa instance with plan application or?
2. Why do you do another token exchange instead of configuring the endpoint like the approuter or the CAP application to directly support the IAS token? This would avoid another request response cycle.

Looking forward to your answer.

Best Regards
Gregor