Authentication and Authorization

Real world Apps Development

Jeffrey Marvin Forones
Mar 8 · 10 min read

This topic is all about sharing the right way of implementing security layers in your application whether it is Web, Mobile or Back end service.

The common mistakes done, when building an application are due to its implementation rather than its design. Especially when dealing with security.

Security is one of the most essential part in the application, And it’s often disregarded because of the lack of time, oversight, not the priority, or maybe because the technical design is still evolving. As a result, it leads to an accidental complexity such as technical gap, security breach and stolen identity on the internet.

As part of our team values, securing any application we build is as important as its business features.

As an example of the cost for not paying attention to the security of an application, Parler becomes the center of the tech industry for being naive to their applications security layer.

There was a recent security incident involving Parler, in January 2021. Which states that their resources were scraped by a female programmer whose twitter handler is @donk_enby. She obtained a large amount of data which worth of 80 TB.

She even described Parler’s archival situation as “A bunch of people running into a burning building trying to grab as many things as we can.”

She described that Parler’s applications major flaws to their system are:

  • Weak API Security Layer ( Authentication & Authorization )
  • Database identification (ID) is not uniquely generated ( UUID )
  • No Database Query Limitations
  • Raw Assets ( Video, Image )

This causes a huge loss of return on investment, and credibility to their application, as you can imagine: the “sanctity” of the data and its security is supposed to be paramount for social medias.

Since we already know the cost and consequences of the lack of security in application development. Now the questions are, how and where do we start implementing the security?

We will cover the Authentication and Authorization, since these layers are described by @donk_enby as the entry to access for her to scrape the described amount of information from Parler.

First we need to understand the difference between Authentication and Authorization, and how they work with each other on your application.

On a higher perspective, their objectives are to Verify the identity of the users and Restrict the list of resources that the user can access within the application.

Commonly Authentication layer, is implemented like when the client populates the required fields then the request will travel to the server or the backend service, then the backend Authenticates the credentials and If successful, then it gives an access token in JWT format back to the client.

This are the basic principles on how authentication login works.

In real world scenario, it’s not enough to make your Authentication layer secure.

Our way of doing so are different. Though we still use the same principles from the first graph but we elevate it by adding a couple of steps.

This steps is called challenge-response authentication.

challenge–response authentication is a family of protocols in which one party presents a challenge and another party must provide a valid answer to be authenticated.

We use NONCE as a challenge response from the backend to be sent to the front-end service.

NONCE or Cryptographic nonce, is a time variant arbitrary number or bit of strings that is only used for a specific purpose in which to verify that the data is used only once.

Within the network traffic between your web or mobile to your backend service, password should NOT be send directly in plain form.

Even hashing the password is still not strong enough and still can be penetrated by middle man attacks.

💡THE IDEA

In the Authentication layer, front-end will send a request to the backend service with a public key in the payload.

Backend will check the origin of the request to make sure it’s in the expected domain. And then generates the cryptographic NONCE and hash it using the public key given from the client.

The generated NONCE will be the response challenge.

The challenge will be sent back to the front-end and will be decrypted using the secret key to get the NONCE.

Now password will be hashed using NONCE as a salt.

SALTS are used to safeguard your password as an additional property to your HASH function to formulate a new set of random strings.

By using this approach, you are preventing the actual password from exposing to middle man attacks.

Then once the user login, the username and hashed password will be sent to the backend service.

Then the backend will verify the hash password using the NONCE as a salt.

Once verified, then backend will generate a JWT which will be sent back to the front-end as a response.

There are advance ways of implementing this principles, and it’s commonly used in secure messages, authentication and blockchain.

Having a good authentication implementation solves the problem of having man in the middle attack or replay attacks from your application.

DYNAMIC PASSWORD | ONE TIME PIN

It’s also accompanied by another layer of security called an OTP service or One time PIN to confirm the legitimacy of the user’s identity though sending an arbitrary unique number to sms or email which is only valid for one login session in a short period of time.

This fixes the problem on the traditional password based authentication. Which is when someone knows your actual password, there is no way of blocking the attempts on accessing your account.

OTP has a variety of implementation such as OTP via SMS, third party authenticator software such as google authenticator or Microsoft authenticator

or using a physical Security Key.

THE ALTERNATIVE

But let’s not forget that if time is really a luxury to acquire, you can also use 3rd party identity provider that caters these complexity for you while getting the same caliber of security or even better.

SINGLE SIGN ON AUTHENTICATION

Another solution which is easier, is to use 3rd party identity provider or we commonly call SSO or single sign on authentication.

The implementation behind it is simpler since you don’t need to develop but rather integrate the identity service to your application.

The idea behind it is,

Once your application is already integrated the identity provider, user doesn’t need to undergo registration or login form since SSO providers are using one click authentication process.

Once the provider successfully identity the user, it returns a callback with the user identifier as a response back to your application.

Then the app can use this information to be recorded to your backend service as a future reference to your resource service.

And then again you can also formulate a JWT response based on the provided user identifier.

In that way the authentication implementation is more manageable.

AUTHORIZATION

In contrast, Authorization is responsible for restricting a certain level of resource which will be accumulated by the application. This includes but not limited to the information which is marked as private by another user and deleted or archives items,

In addition, it is also paired to the Authentication layer. It needs to accumulate a short lived access token given after the user is authenticated in order for the resources to be accessed.

It’s an identity provider that holds a signed JWT claims that is used by an application for identity confirmation.

JWT is an open standard (RFC 7519), which the intent is to secure the information in transit between services in JSON object format.

It consist of 3 parts, which are the Header, Payload and Signature

Header or Authorization header describes the algorithm that is used to generate your token and type.

{
"alg": "HS256",
"typ": "JWT"
}

For this example, JWT token has an authorization header that contains the HS256 algorithm and a type of JWT.

TIPS: If you can, better have an architecture on your systems that changes the algorithm per user. if user 1 is using HS256 algorithm, on the other hand user 2 should not be identical to the first one.

{
"sub": "1234567890",
"name": "Jeffrey Forones",
}

Payload are claims or statements that describes your user entity

In Reality, payload should be short lived, specially if it contains viable information. In this case, preventing an opportunity on the system to have a security breach.

In addition, setting a shorter expiration is vital. The common practice is expiration should not be more than 15 minutes.

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

Signature is a combination of the encoded header, payload and a Secret key

Secret key is an arbitrary number or string that should be used once in your cryptographic communication. In this example, we are using it in our JWT.

This is an example of the digitally signed JWT Token, each color represents sections in which the red part is the Header, pink is for the payload and teal is for the signature, separated by a dot (.) .

THE TAKEAWAY

Authentication is to verify and generate a short lived access token.

Authorization is to restrict the amount resources to the consumer and validate its access rights by using the access token.

DATA IN TRANSIT

Now since we have already described each components intimately, We now proceed on how to correlate with each other. Therefore it’s immensely important that how they should connect each service.

Hypertext Transfer Protocol Secure

Let’s start with the in transit protocol which should be in HTTPS, for HTTPS encrypts and secures the information while it’s being transported from the front-end to the backend service.

This prevents a middle man attack from reading the context of your request while the payload is under in transit.

Packet sniffers is an example in which allows you to see everything that is traveling on the network.

DATA VALIDATIONS

Since everything is not put together, we haven’t forgotten the validation principle for the 2 entities which are your front-end and backend API.

In login page, generically, validations will always be a requirement. Email field should be in correct format, password should be hidden and all fields are required before we submit.

But on the backend side, field validations are commonly assumed since front-end already validated the fields and then backend service will just directly proceed to query validation. Not knowing that this little things will cause big flaws with your application.

⚠️ CAUTION!

There are a bunch of tools that can bypass front-end by using API’s directly for requesting information. It will help your backend development to be independent with your front-end.

One of which is POSTMAN

Postman is a reliable tool in creating backend service and so does a good documentation tool for the front-end to be used for integration.

But it’s also vital for those who attempts to disrupt your application.

Therefore it’s a necessity for both service to validate the required fields to prevent the attack.

Front-end should handle the field validation.

Backend should handle the property validation send from the front-end.

Front-end and Backend should have the same validation checking in both field and property

Then backend can do its 2nd layer of validation under database query for user identity recognition.

But do take note that the principle should be applied cross all your application and not just for your login page.

We always replicate the validation on the front-end. As i’ve discussed earlier. “each service should not trust each other”

CONCLUSION

In conclusion to this topic, there are no coding presented. It doesn’t concern on what programming language you will use in your web, mobile or backend service.

Because for us, to understand the real world problem, It’s about the values and principles which is more important that relies within our vision to be better engineers.

Geek Culture

Proud to geek out. Follow to join our +1.5M monthly readers.