Category Archives: OAuth2.0

Techstack Framework for RentersFeedback

As a developer, we make different choices based on what is available to us and what we know. But are those choices always better? They may not or they may. It really depends. In this post, I describe the techstack framework that I used to build Renters Feedback.

You can read my post, how I came up with an idea to build an application for renters feedback.

I wanted to describe the process of the choices I made to choose a tech stack framework for building the application. Considering my expertise in Spring Boot, it was a default choice to use to build this application. There are other factors I took into account like the ease of coding, ease of deploying as a microservice-based application in the cloud, and docker.

Techstack Framework for Renters Feedback

Development Framework For Renters Feedback

For developing the application, my focus was on the re-usability of code. Since I have written few applications as part of this blog using Spring Boot, there was authentication, login forms, sign up forms, most of that code was readily available. One thing I have to think through for RentersFeedback was database modeling.

Database Framework for Renters Feedback

For developing a database based application, I used mysql as a development database. In production, I changed that to postgresql . 

Why database change? 

Heroku support for mysql wasn’t straightforward, so I preferred what was available by default and it was postgresql. I have to do a few changes to mysql scripts. I could have automated these scripts through liquibase, but I preferred not to for the first version of the product. In the future, when I plan to add more changes to the database model, I will add liquibase-based scripts.

Authentication Scheme

There were some questions about why a user needs to login on a RentersFeedback website. Well, someone has to post those reviews before people can browse it. You need to login if you want to post a review.

The easiest choice was to have form-based login even though it is getting old and not safe. I still feel most users would use email to login. User passwords are stored in an encrypted and hashed format in the database.

Another mechanism, I decided to add, was OAuth2 OpenId protocol by using Google API for the same. It was easy to implement and something I have expertise in.

I could add other social logins, but I prefer to keep it simple and if the need arises, I will add those logins in the future.

Using Google API, made me use Redis Cache. I wasn’t planning to use cache since the application is still in nascent stages, but now it is there, so future scaling would be easier from a performance perspective.

User Interface

The user interface was built using Spring Boot provided thymeleaf templates along with Twitter’s Bootstrap CSS library and javascript library. For the search feature, I have used javascript library of Google search APIs.

After deploying the application on Heroku, I came across a few issues about having forms available publicly. To avoid spams, I will be adding Captcha on those forms. I will show how to use reCaptcha APIs in the next post.

To allow users to reset the password, I have used Spring Boot Email system. This was an easy implementation once you know how the forgot your password flow works.

Deployment Environment

I used Heroku to deploy my application. Heroku has great documentation. It’s very easy to sync up with your GitHub repository. So if you push your changes to GitHub, it will sync up to build and deploy on Heroku.

Questions

Choosing the right tech stack framework for your application can be a difficult task if you are a beginner.  Since I have experience in building applications, choosing this techstack framework for Renters Feedback was a straightforward choice. If you have any questions about implementation, why I used certain technology, and how it can be improved, you can post a comment on this blog and I will answer those questions.

 

Json Web Token (JWT) – Introduction

If you have worked in OAuth or OpenID or authorization part of security, you must have across a term called JSON Web Token – JWT (Pronounced as JOT).

In this post, I will explain its components and a few tips and tricks. In previous securing spring boot rest api post, I showed how to use JWT to secure a REST API.

JSON Web Token (JWT) is a JSON object defined in a way where participating parties agree with a certain norm. This object contains information that can identify a user or a participating party.

JWT is encrypted and signed, so it is used securely. Even if a third party gets access to JWT, that party will ever be able to decrypt it if it has a public key with which it was signed. Also usually JWT is valid for a limited time, so a hacker will not be able to use JWT if it has expired and the hacker was able to decrypt JWT.

There are a few use cases when you can use JWT.

  1. Single Sign-On – In some authorization scenarios, JWT is used to encrypt user information in a token for authentication purposes.
  2. JWT offers a lot of security, so it helps to exchange information between parties secretly.

 

Components

JSON Web Token consists of three parts – header, payload, and signature. Once you create a JWT using these three parts, you compact that JWT. So every JWT is in a compact form.

hhhhhh.pppppppp.ssssss

Header of JSON Web Token

Every Json Web Token contains header, payload and signature part. In header part, you will have two important elements – algorithm type as alg and key id as kid , but instead of these two elements, it can also contain alg and type to indicate what type of the token this is.

{
   "alg":"HS256",
   "kid": "NHAS42KWE49825JADTWWQRWR"
}

Payload

The payload is the part that contains actual data in JWT. Basically this data is in the form of claims. Claims are identifying information about the user or entity. But other than user information (sub), it also contains some important information at what time the token was issued – iat, who is the issuer – iss, what is the expiration time exp , what is the not before used time nbf .

Example of JWT payload will look like below:

{
  "sub": "betterjavacode\\userabc",
  "created": 1571755568798,
  "iss": "betterjavacode.com",
  "client_id": "randomclient",
  "nbf": 1571755569,
  "scope": "[Email]",
  "exp": 1571759169,
  "expires_in": "3600",
  "iat": 1571755569,
  "jti": "qqwrwe-wewewt-34343re-343gtrtr-323222"
}

Signature

Signature to sign JWT is created by Base64 URL encoding of header + Base64 URL encoding of body and a secret key and all this will be signed by using a signature algorithm of server choice, for this example it is HMACSHA256. The server which is creating JWT, will not share a secret key with anyone and will have its own policies to create that secret key. It can make the public key available to requested clients.

When to use JWT?

The usual use case for JWT is for authentication purposes since it can contain user data. Tokens are valid for a short duration, so they can’t be compromised. When the user accesses a protected resource, the user agent sends JWT in authorization header using Bearer schema. As a precaution, a token should not contain any secret information. In that case, even if a JWT is stolen, nobody can use JWT data for any other purposes.

JWT is a more compact version of token which was usually exchanged through Security Assertion Markup Language (SAML).

Conclusion

In this post, we discussed the details of JWT and when to use it.

References

  1. Specification of JSON Web Token – Specifications
  2. JSON Web Token – Open Id Specifications