Skip to Content
Technical Articles
Author's profile photo Raja Prasad Gupta

Fundamentals of Security in SAP BTP – What is OAuth and how does it work?

This blog series is mainly targeted for developers and administrators. If you are someone who has gone through the plethora of tutorials, documentation, and presentations on security topics in SAP BTP and still lacks the confidence to implement security for your application, you have come to the right place.

In this blog series, we will learn:

  • How to protect an app in SAP BTP, Cloud Foundry environment from unauthorized access
  • How to implement role-based features
  • How SAP Identity Provider and Single-sign-on works

For ease of reading, I have split this in multiple blogs, which are:

  1. Fundamentals of Security in BTP: Introduction
  2. Fundamentals of Security in BTP: OAuth Concept [current blog]
  3. Fundamentals of Security in BTP: Implement Authentication and Authorization in a Node.js App
  4. Run Node.js Applications with Authentication Locally

 

What are we going to learn in this blog?

In this blog, we will focus on OAuth. We will learn what OAuth is, how does it work.

 

Why was OAuth introduced?

Let’s first understand why OAuth was introduced, what problem did it solve?

We know that we should never ever share our passwords. But there are use cases which require us to authorize a website to use the service of another. For example, you may need to tell Facebook that it’s ok for ESPN.com to access your profile or post updates to your timeline. Instead of asking for your Facebook password, ESPN can use a protocol called OAuth.

 

What is OAuth?

OAuth is an open standard for applications and websites to handle authorization.

OAuth doesn’t share password data but instead uses authorization tokens to prove an identity between consumers and service providers. It is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password.

 

OAuth:

  • Avoids storing credentials at the third-party location
  • Limits the access permissions granted to third parties
  • Enables easy access right revocation without the need to change credentials

In this way, OAuth mitigates some of the common concerns with authorization scenarios

 

Note that OAuth is about authorization and not authentication. Authorization is asking for permission to do stuff. Authentication is about proving you are the correct person because you know things.

 

SAML vs. OAuth

The Security Assertion Markup Language (SAML) is an open standard based on XML, which many enterprises use for Single-Sign On (SSO).

SAML enables enterprises to monitor who has access to corporate resources.

 

There are many differences between SAML and OAuth.

SAML uses XML to pass messages, and OAuth uses JSON.

OAuth is much more lightweight and an ideal fit for system-to-system communication. While SAML is geared towards enterprise security.

The key differentiator is:

  • OAuth uses API calls extensively, which is why mobile applications, modern web applications, game consoles, and Internet of Things (IoT) devices find OAuth a better experience for the user.
  • SAML, on the other hand, uses a session cookie in a browser that allows a user to access certain web pages – great for short-lived work days, but not so great when have to log into your smart watch every day.

 

How does OAuth work?

Let’s say you want ESPN to post data directly on your Facebook page.

 

There are 4 actors in the game.

Resource Server: The server hosting the protected resources (e. g. Facebook, Twitter)

Resource Owner: User who owns the data in the resource server. For example, a User is the Resource Owner of his Facebook profile.

Client: The application that wants to access your data (e. g. ESPN.com)

Authorization Server: The main engine of OAuth. It allows Resource Owner to delegate his authorization to Client.

 

The entire flows work in 2 stages.

  1. First User authorizes the ESPN – Front Channel Flow
  2. ESPN Posts on User’s Facebook Page – Back Channel

 

Front Channel Flow:

Step 1 – User Shows Intent to Client

User (Resource Owner): “Hey, ESPN, I would like you to be able to post directly to my Facebook page.”

ESPN (Client): “Great! Let me go ask for permission.”

 

 

Step 2 – The Client seeks Permission from Authorization Server

ESPN (Client): “Authorization Server, I have a user that would like me to post to his page. Can I have a Request Token?”

ESPN sends the request to Authorization Server with desired scopes. Scope is nothing but individual tasks (e.g. access friend list, post on page etc.)

Authorization Server: “Sure.  But let me get a confirmation from the User.”

 

Step 3 – Authorization Server asks for confirmation from user

Authorization Server sends a consent dialog to User, saying “do you authorize ESPN to do X, Y and Z with your Facebook account?

 

Step 4 – User Confirms the Authorization Server request

User views the consent dialog and agrees.

A Request Token is sent to ESPN.

 

Back Channel Flow

Step 1 – ESPN asks for Access Token

ESPN: “Authorization Server, can I exchange this Request Token for an Access Token ()?”

 

Step 2 – Authorization Server provides Access Token

Authorization Server: “ESPN, here’s your Access Token and Secret.”

 

Step 3 – ESPN posts on User’s Facebook Page

ESPN: “Facebook, I’d like to post this link to User’s page.  Here’s my Access Token

Facebook: “Done!”

 

Let’s take another example:

You watch a video on YouTube, and you want to share that on your Facebook wall. Here:

  • You are the resource owner
  • YouTube is the client
  • Facebook is the resource server and authorization sever.

 

OAuth 1.0 Vs OAuth 2.0

There are two versions of OAuth: OAuth 1.0a and OAuth 2.0. These specifications are completely different from one another and cannot be used together.

Nowadays, OAuth 2.0 is the most widely used form of OAuth. OAuth 2.0 is the one used in SAP BTP.

 

JWT Token

We learnt that OAuth call flows uses Access Token and Request Token. Usually, these tokens are JSON Web Tokens (JWT).

JWT (pronounced “jot”) is an open standard that defines a compact and self-contained way for securely transmitting information between parties.

JWT is widely used in OAuth for securely transmit user information and access rights. You can check how XSUAA acts as the central administrator creating dedicated & tailored JWTs for our application and app router.

 

A JWT Token consists of three main components:

Header: Declaration of the used hashing and signing algorithms

Body/payload: Might be anything. For example, information about the user, the issuer and all the scopes.

Signature: The signature allows the integrity of the JWT.

All these parts can be combined and converted with base64 so it is easier to add them in other data structures:

const token = base64urlEncoding(header)
              + "." + base64urlEncoding(payload)
              + "." + base64urlEncoding(signature)

 

Advantages of using JSON Web Token

JSON Web Tokens (JWT) are better than SAML tokens in many ways.

First of all, since JSON is less verbose than XML, JWT Tokens are smaller in size, making JWT more compact than SAML. This makes JWT a good choice to be passed over network.

 

JSON parsers are extremely common in most programming languages because they map directly to objects. Conversely, XML doesn’t have a natural document-to-object mapping. This makes it easier to work with JWT than SAML assertions.

 

A simple real-life analogy of JWT token is – access card (or key) you use every day to enter your office. Like your access card has your user and access rights information, the JWT Token also contains the information about user e.g. id, email, address, access rights etc.

JWT token is cryptographically signed by the XSUAA, which means others cannot alter the user information of a token. However, if they somehow get access to the token, they can cause a lot of harm as they can access all the data the user has access to. That’s the reason, JWT tokens are usually only be passed between applications and servers and never exposed to end user. This is also the reason, why App Router takes care of attaching JWT token to request instead of sending JWT token to browser.

 

I hope you got the basic idea of OAuth and JWT Token. If you have any question, let me know in the comment.

Next blog in the series:

Assigned Tags

      12 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Martin Pankraz
      Martin Pankraz

      Hey Raja Prasad Gupta,

      interesting series you started there. How about making it complete by adding a view on SAP Identity Authentication Service and integration with industry standard corporate Identity Providers such as Azure Active Directory? Have a look here at our best practices.

      KR

      Martin

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Martin Pankraz ,

      Thanks. Perhaps a good idea.

      I have added the best practices in first blog of the series.

       

      Regards,

      Raja

      Author's profile photo Denys van Kempen
      Denys van Kempen

      Hi Martin, Raja

      FYI and for the reader ...

      For the SAP HANA Academy, we recorded some tutorials on the topic (SAP Cloud Platform = SAP BUsiness Technology Platform in this context)

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Denys van Kempen ,

      Thanks for mentioning this. I truly admire the blogs/video posted by HANA Academy. I am planning to put all these references at final blog in the series.

       

      Regards,

      Raja

      Author's profile photo Shantanu Sharma
      Shantanu Sharma

      This is an outstanding blog Raja. As a BTP architect, this is one of the common questions I encounter from customers and the call flow as well as the sequence diagram are really excellent. Thank you for sharing.

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Thanks Shantanu.

      Author's profile photo Wolfgang Reis
      Wolfgang Reis

      Thanks a lot. Very good informative blog. I hope you'll find time to do the other planned items in your series.

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Wolfgang Reis ,

      I just published the next blog - Fundamentals of Security in BTP: Implement Authentication in a Node.js App

      Author's profile photo Torsten Koch
      Torsten Koch

      My recommendation: Use the Managed App Router Service ( CF) instead, in order to reduce all this the native stuff, and as streamlined approach for App authentification and routing

      Good Luck!

       

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Torsten,

      Thanks for the feedback.

      This blog is more focussed on understanding the core concepts. Managed app router vs Stand alone app router is a separate topic, both having their pros and cons. However, even in case of Managed app router, the underlying concepts of IdP and XSUAA will be more or less same.

      Author's profile photo Matthias Heiler
      Matthias Heiler

      Hello Raja,

      in the text of both channel the front and back channel flow you talk about a request token, but in the graphic you talk about a resource token. So, I believe both are the same, or is this a misspelling?

      BR
      Matthias

      Author's profile photo Raja Prasad Gupta
      Raja Prasad Gupta
      Blog Post Author

      Hi Matthias Heiler ,

      A good catch!

      Thanks a lot. I have corrected it.

       

      Regards,

      Raja