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:
- Fundamentals of Security in BTP: Introduction
- Fundamentals of Security in BTP: OAuth Concept [current blog]
- Fundamentals of Security in BTP: Implement Authentication and Authorization in a Node.js App
- 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.
- First User authorizes the ESPN – Front Channel Flow
- 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 queries, let me know in comment or get in touch with me at LinkedIn!
Next blog in the series:
