JSON Web Tokens (JWT)

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

A JWT is composed of a HEADER, a PAYLOAD and a SIGNATURE.

The followings are the steps to produce a JWT:-

  1. Encodes HEADER by using base64url
    Sample HEADER data in JSON:
    {
    “alg”: “HS256”,
    “typ”: “JWT”
    }
  2. Encodes PAYLOAD by using base64url
    Sample PAYLOAD data in JSON:
    {
    “sub”: “1234567890”,,
    “name”: “John Doe”,
    “iat”: 1516239022
    }
  3. Joins the encoded HEADER and PAYLOAD together with period (.), and signed with a secret key using the hashing algorithm specified in the JWT header.

    HEADER.PAYLOAD.SIGNATURE

    For example:
    eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.B6H4S0WFqJnNq8byQs9BUcnf9JEHbnSJ0oSvhLF1dkY

References:
https://jwt.io/
https://en.wikipedia.org/wiki/JSON_Web_Token
https://medium.com/vandium-software/5-easy-steps-to-understanding-json-web-tokens-jwt-1164c0adfcec

How to make a executable Jar file in Maven

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-dependency-plugin</artifactId>
        <executions>
          <execution>
            <phase>process-sources</phase>
            <goals>
              <goal>copy-dependencies</goal>
            </goals>
            <configuration>
              <outputDirectory>
              ${project.build.directory}/lib
              </outputDirectory>
            </configuration>
          </execution>
        </executions>
    </plugin>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
        <archive>
          <manifest>
            <addClasspath>true</addClasspath>
            <classpathPrefix>lib/</classpathPrefix>
            <mainClass>
            com.mycompany.mavenproject1.MyClass1
            </mainClass>
          </manifest>
        </archive>
      </configuration>
    </plugin>
  </plugins>
</build>

oAuth2.0 Flow (Authorization Code Flow)

OAuth 2.0 specification defines 4 types of authorization flows (Authorization Code, Resource Owner Password Credentials, Implicit, and Client Credentials)

This post is only focus on the authorization code flow.

The followings are the steps of the flow:

  1. The client / app makes and authorization requests to authorization server (e.g. Google, Facebook), and the authorization server returns an authorization page to client.
  2. User enters credentials on the page (e.g. login id, password), and checks the permissions requested by client.
  3. The credentials submitted to authorization server.
  4. The authorization server validates the credentials and redirect user back to the client with an authorization code by using the
    redirect Url prepared at step 1 (See the sample request of step 1).
  5. The client and the authorization exchanges the authorization code for an access token.
  6. The client access resources on the resource server by providing the access token granted at step 5.

The followings are the sample request and response of the flow:

Request to authorization server (step 1):
GET {Authorization Endpoint}
?response_type=code // – Required
&client_id={Client ID} // – Required
&redirect_uri={Redirect URI} // – Conditionally required
&scope={Scopes} // – Optional
&state={Arbitrary String} // – Recommended
&code_challenge={Challenge} // – Optional
&code_challenge_method={Method} // – Optional
HTTP/1.1
HOST: {Authorization Server}

Response from authorization server (step 4):
HTTP/1.1 302 Found
Location: {Redirect URI}
?code={Authorization Code} // – Required
&state={Arbitrary String} // – Optional. Normally a random generated unique identifier

Request to authorization server to obtain token (step 5):
POST {Token Endpoint} HTTP/1.1
Host: {Authorization Server}
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code // – Required
&code={Authorization Code} // – Required
&redirect_uri={Redirect URI} // – Required if the authorization
// request included ‘redirect_uri’.
&code_verifier={Verifier} // – Required if the authorization
// request included
// ‘code_challenge’.

Response from authorization server with access token (step 5):
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
“access_token”: “{Access Token}”, // – Required
“token_type”: “{Token Type}”, // – Required
“expires_in”: {Lifetime In Seconds}, // – Optional
“refresh_token”: “{Refresh Token}”, // – Optional
“scope”: “{Scopes}” // – Mandatory if the granted
// scopes differ from the
// requested ones.

Ps. For security wise, oAuth2.0 must run on HTTPS.

References:
https://medium.com/google-cloud/understanding-oauth2-and-building-a-basic-authorization-server-of-your-own-a-beginners-guide-cf7451a16f66
https://medium.com/@darutk/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85

Set environment variable permanently in Linux

To set the environment variable in Linux permanently, you can insert the export command into startup file.

Example of command to set environment variable:
export JAVA_HOME=/usr/local/java/jre1.8

There are several startup files in Linux environment.

To set environment variable for a particular user, you can use ~/bashrc, ~/bash_profile or ~/bash_login.

If you plan to set system wide environment variable, you can use /etc/profile, /etc/bashrc, etc/profile or create a custom .sh file in profile.d folder.

Here the execution sequence of the startup files:-

Interative login shell (e.g login remotely via ssh)

  1. /etc/profile
    1.1 all the .sh files in /etc/profile.d (*if any)
  2. ~/.bash_profile or ~/.bash_login or ~/.profile (*executes only the first of those files found)

Interactive non-login shell (e.g Gnome terminal)

  1. /etc/.bashrc
  2. ~/.bashrc

Example:

Reference: https://shreevatsa.wordpress.com/2008/03/30/zshbash-startup-files-loading-order-bashrc-zshrc-etc/