DEV Community: Muhammad Yahya Muhaimin

Lessons Learned from Developing Serverless Workflow Runtime Implementation

Muhammad Yahya Muhaimin — Tue, 26 Jul 2022 01:23:02 +0000

At Hash Rekayasa Teknologi, we've been developing and using MocoBaaS, a Backend-as-a-Service solution.
One of the features for implementing business logic is Custom Script.

This feature has served us well for many use cases.
However, there are some use cases that consist of multiple steps. They can be implemented by "chaining" multiple scripts, one script triggering another. While this can get the job done, it's hard to keep track of the steps that were executed.

Imagine we have a use case like Marketplace Order:

DISCLAIMER: It may not represent a real world use case.

Create Order
Confirm Payment
Confirm Delivery
Confirm Completed

It can be done by defining this flow:

Script: create-order
- Triggered By: HTTP source
- Triggers: create-order-success event
Script: confirm-payment
- Triggered By: Event source
- Triggers: confirm-payment-success event
Script: confirm-delivery
- Triggered By: Event source
- Triggers: confirm-delivery-success event
Script: confirm-completed
- Triggered By: Event source

With the flow above, the scripts were executed as is. There is no centralized mechanism of tracking the executed steps, whether they were executed properly or not.

Serverless Workflow to the rescue

Among workflow languages out there, we choose Serverless Workflow. It's a vendor-neutral, open-source and community-driven workflow ecosystem.
The workflow definition can be written in JSON or YAML format.
And then there are SDKs available in various programming languanges, like Java, Go, TypeScript, .NET, Python.

The Marketplace Order use case above can be defined like this:

id: marketplaceorder
version: "1.0"
specVersion: "0.7"
name: Marketplace Order Workflow
description: Create and process orders on the marketplace.
start: CreateOrder
functions:
  - name: createOrderFunction
    operation: mocobaas://marketplace-order#create-order
  - name: confirmPaymentFunction
    operation: mocobaas://marketplace-order#confirm-payment
  - name: confirmDeliveryFunction
    operation: mocobaas://marketplace-order#confirm-delivery
  - name: confirmCompletedFunction
    operation: mocobaas://marketplace-order#confirm-completed
states:
  - name: CreateOrder
    type: operation
    actions:
      - functionRef: createOrderFunction
    transition: ConfirmPayment
  - name: ConfirmPayment
    type: operation
    actions:
      - functionRef: confirmPaymentFunction
    transition: ConfirmDelivery
  - name: ConfirmDelivery
    type: operation
    actions:
      - functionRef: confirmDeliveryFunction
    transition: ConfirmCompleted
  - name: ConfirmCompleted
    type: operation
    actions:
      - functionRef: confirmCompletedFunction
    end: true

And this is the diagram visualization:

If you are new to Serverless Workflow, or workflow in general, you may have so many questions about that 😁

I recommend you to watch this presentation:

And then read the official Serverless Workflow examples and specification:

Version 0.7: examples, specification.
Version 0.8: examples, specification.

Let me continue the story...

What we need to build is a runtime implementation that execute workflows based on the definitions.
Golang has become an important part of our stack at Hash Rekayasa Teknologi. So we simply choose the Go SDK for Serverless Workflow. Although I didn't try other SDKs, I'm sure there shouldn't be much difference to what I'm using here.
The most important question with the SDK: What it does and doesn't?

It does:

Parse workflow JSON and YAML definitions.
One workflow definition has a hierarchical structure. Each definition from top level to sub-levels will be represented as a Model, such as Workflow, State, Action, Function, Retry.

It doesn't:

There is no Workflow Instance representation. For the execution, you have to define the unique identifier yourself.
The duration values in ISO 8601 duration format are not parsed.
The workflow expressions in jq format are not parsed.

With those limitations, there doesn't seem to be much we can do with the SDK. Just parse the workflow definition and use the hierarchical structure as a guide for executions.

package sw

import (
    "errors"
    "os"
    "path/filepath"

    "github.com/google/uuid"
    "github.com/serverlessworkflow/sdk-go/v2/model"
    "github.com/serverlessworkflow/sdk-go/v2/parser"
)

type StartWorkflowResult struct {
    InstanceID string `json:"instanceId"`
}

var workflows map[string]*model.Workflow

func LoadWorkflows() error {
    const definitionsDir = "definitions"

    dirEntries, err := os.ReadDir(definitionsDir)
    if err != nil {
        return err
    }

    workflows = make(map[string]*model.Workflow)

    for _, entry := range dirEntries {
        name := entry.Name()
        path := filepath.Join(definitionsDir, name)
        wf, err := parser.FromFile(path)
        if err != nil {
            return err
        }

        workflows[name] = wf
    }

    return nil
}

func StartWorkflow(name string, input map[string]interface{}) (*StartWorkflowResult, error) {
    wf, ok := workflows[name]
    if !ok {
        return nil, errors.New("Workflow not found: " + name)
    }

    instanceID := uuid.NewString()

    // Start a new instance.
    // Parameters: instanceID, wf, input

    return &StartWorkflowResult{instanceID}, nil
}

Here we store the Workflow models in a map, so the LoadWorkflows() function only needs to be called once.
And then the StartWorkflow() function will be called in every execution.

Take notes for the implemented features

We may not implement all the features in the specification. One thing we can do is document them. Each feature will have status:

implemented according to the spec 🟢🟢
implemented, but not according to the spec or using own standard 🟢🔴
not/not yet implemented 🔴

I took notes on a spreadsheet. You can see it here.
I use my native language, Bahasa Indonesia.
And it's not complete. I take note of a definition only when I start implementing it.

Let's see one example, the Function Definition:

As we know, service call is defined here.
The workflow runtime is written in Go, while the scripts are written in JavaScript (Node.js).
MocoBaaS already has an internal RPC mechanism, so we want to use "custom" type.
In spec v0.8, there's "custom" type. But as of this writing, the Go SDK only supports spec v0.7.

As you can see, we tried to stick to the spec as far as we could. But sometimes we have to use our own standards.

Executing workflow

The Marketplace Order Workflow has a linear flow, from create order to confirm completed. This is the directory structure containing workflow definition and scripts:

.
└── marketplace-order
    ├── definition.sw.yaml
    └── scripts
        ├── confirm-completed.js
        ├── confirm-delivery.js
        ├── confirm-payment.js
        └── create-order.js

The end result will be a JSON like this:

{
  "createOrder": true,
  "confirmPayment": true,
  "confirmDelivery": true,
  "confirmCompleted": true
}

When the workflow is executed, starting with create-order.js, data is a new object:

module.exports = async (ctx) => {
  return {
    data: { createOrder: true },
  };
};

Next, confirm-payment.js extends the data from previous state:

module.exports = async (ctx) => {
  return {
    data: { ...ctx.data, confirmPayment: true },
  };
};

And so on.

Tracking workflow execution

As written in the spec:
Depending on their workflow definition, workflow instances can be short-lived or can execute for days, weeks, or years.

There is no recommendation on how to store the tracking information. Any database can be used.
We need to handle these requirements:

One instance can have more than one states.
The state's data input is typically the previous state's data output.
If the state is the workflow starting state, its data input is the workflow data input.
When workflow execution ends, the data output of the last executed state becomes the workflow data output.

For example, we have two tables:

instances
instance_states

The Marketplace Order Workflow execution can be stored like this:

Retrying actions

If a state returning an error, we can leave it as the final result or define a retry policy.
For example, we have a Chance of Success Workflow.

Directory structure:

.
└── chance-of-success
    ├── definition.sw.yaml
    └── scripts
        └── chance.js

chance.js will randomize a boolean. If true, returns data. If false, returns error:

const chance = require("chance").Chance();

module.exports = async (ctx) => {
  const isTrue = chance.bool({ likelihood: ctx.data.likelihood });

  if (!isTrue) {
    return {
      error: { message: "failed" },
    };
  }

  return {
    data: { message: "success" },
  };
};

And the workflow definition contains a retry definition:

id: chanceofsuccess
version: "1.0"
specVersion: "0.7"
name: Chance of Success Workflow
description: Try your chance of success. Retry if failed.
start: TakeAChance
functions:
  - name: chanceFunction
    operation: mocobaas://chance-of-success#chance
retries:
  - name: chanceRetryStrategy
    delay: PT10S
    maxAttempts: 3
states:
  - name: TakeAChance
    type: operation
    actions:
      - functionRef: chanceFunction
        retryRef: chanceRetryStrategy
    end: true

With that retry definition, the runtime will perform this mechanism:

The maximum attempts is 3 times.
There is 10 second delay between retries.
If we get data before maxAttempts, there will be no more retries.
If maxAttempts is reached, there will be no more retries, regardless of the result.

Before we can use the delay duration, it needs to be parsed. For example, I use sosodev/duration and it works well.

Diagram visualization

Generating a diagram visualization from the workflow definition is really helpful, especially when you have complex workflows.
One way is that you can use the Web Editor in the official website. It can generate diagram from JSON or YAML, but the linter in the text editor will always expect JSON.

For VS Code users, there's an official extension, But as of this writing, it is outdated, only supports spec v0.6.
A better alternative is to use an extension from Red Hat. It supports spec v0.8. It also works well with spec v0.7. The only requirement is you must name the definition files to *.sw.json, *.sw.yaml or *.sw.yml.

Caveat:
Looks like those tools use the same generator, as they produce the same diagram visualization. I noticed that they can only visualize the flow, but don't include other details, such as functions or retries.

Closing Thoughts

Workflow is quite a huge feature. And as you can see, Serverless Workflow offers a great flexibility between standard and customization. But if you need more training wheels in using a workflow system, there may be better solutions out there.

We haven't implemented most of the Serverless Workflow features yet.
For example, the workflow expressions I mentioned above. Using a library like itchyny/gojq looks promising, although I haven't tried it.
But at least this little effort is enough for a minimal functioning system.

Well, hope you enjoyed this article and found it useful 😉

[ID] Otentikasi Skema Hybrid: JWT + userinfo

Muhammad Yahya Muhaimin — Mon, 23 May 2022 01:32:02 +0000

Sebagai pengembang backend, barangkali Anda pernah membangun sendiri sistem otentikasi untuk aplikasi yang Anda buat. Jika Anda mengelola session, misalnya dengan memanfaatkan database, maka itu disebut stateful.
Kebalikan dari stateful adalah stateless. Beberapa standar otentikasi stateless yang umum di antaranya JWT dan SAML.^[1]

Di artikel ini kita akan mengupas bagaimana JWT digunakan dan mengapa kita tidak bisa mengandalkan dia seutuhnya.

Aplikasi demo yang akan kita buat berbasis framework Fiber.
Jika Anda punya preferensi lain, secara prinsip soal JWT dan otentikasi skema hybrid ini harusnya sama.

Development Tools

Cara Kerja JWT

JWT (dibaca "jot") merupakan sebuah standar internet untuk pertukaran informasi, dituangkan dalam dokumen RFC 7519.
JSON Web Token, sesuai namanya, dia membawa payload dalam bentuk objek JSON. Setiap properti di dalamnya disebut dengan claim.

Langsung saja kita mulai dengan membuat sebuah folder, misalnya dengan nama how-to-hybrid-auth. Kemudian masuk ke folder tersebut, buka terminal dan ketik:

go mod init how-to-hybrid-auth

Maka akan muncul file go.mod.
File ini bersama dengan file go.sum nantinya digunakan untuk mencatat berbagai dependency project. Kecuali project yang zero dependency, hanya membutuhkan standard packages, maka hanya akan ada file go.mod, tanpa file go.sum.

Di tutorial ini struktur projectnya seperti ini:

.
├── go.mod
├── go.sum
├── main.go
└── pkg
    ├── authenticate
    │   └── handler.go
    ├── getaccess
    │   └── handler.go
    ├── getprofile
    │   └── handler.go
    ├── jwt
    │   └── jwt.go
    └── store
        ├── seeder.go
        └── store.go

1. Data contoh: users

Misalnya ada data profil pengguna sebagai dasar untuk mengidentifikasi pengguna aplikasi. Di sini kita simpan datanya dalam file JSON.

Isi file pkg/store/store.go:

package store

import (
    "encoding/json"
    "os"
)

type (
    Item map[string]interface{}
    Data map[string]Item
)

func Get(storeName string) (Data, error) {
    // Read file content.
    content, err := os.ReadFile(storeName + ".json")
    if err != nil {
        return nil, err
    }

    // Parse it.
    var data Data
    if err := json.Unmarshal(content, &data); err != nil {
        return nil, err
    }

    return data, nil
}

func Set(storeName string, data Data, overwrite bool) error {
    // Serialize the data.
    out, err := json.MarshalIndent(data, "", "  ")
    if err != nil {
        return err
    }

    if overwrite {
        // Write file (overwrite existing file).
        return os.WriteFile(storeName+".json", out, os.ModePerm)
    }

    // Check if file doesn't exist.
    if _, err := os.Stat(storeName + ".json"); errors.Is(err, os.ErrNotExist) {
        // Write file.
        return os.WriteFile(storeName+".json", out, os.ModePerm)
    }

    return nil
}

Fungsi Set untuk memformat data menjadi JSON dan menulisnya ke file, sedangkan fungsi Get untuk membaca file JSON dan mengonversinya menjadi data.

Dan isi file pkg/store/seeder.go:

package store

func Seed() error {
    users := Data{
        "rI3sMqctRUv9Cv9CdvJIV": Item{
            "name": "Agni",
            "role": "Owner",
        },
        "ELjvSoCYudoMnlEYlhCjP": Item{
            "name": "Bisma",
            "role": "Maintainer",
        },
        "5hkcRZcrOWTxaeFhq3EdD": Item{
            "name": "Catur",
            "role": "Developer",
        },
    }
    if err := Set("users", users, false); err != nil {
        return err
    }

    return nil
}

Fungsi Seed akan membuatkan data awal jika belum ada.

Sekarang gunakan fungsi tersebut di entry point aplikasi, yaitu file main.go:

package main

import (
    "how-to-hybrid-auth/pkg/store"
)

func main() {
    // Seed some data.
    if err := store.Seed(); err != nil {
        panic(err)
    }
}

Jika kita jalankan aplikasi dengan perintah:

go run main.go

Maka akan muncul file users.json, yang berisi data awal seperti definisi di atas.

2. Membuat Access Token

Di sini kita mulai menggunakan Fiber, diawali dengan sebuah endpoint API untuk membuat Access Token.

Ubah file main.go seperti berikut:

package main

import (
    "log"

    "github.com/gofiber/fiber/v2"

    "how-to-hybrid-auth/pkg/getaccess"
    "how-to-hybrid-auth/pkg/store"
)

func main() {
    // Seed some data.
    if err := store.Seed(); err != nil {
        panic(err)
    }

    // Create Fiber app.
    app := fiber.New()

    // External endpoints.
    app.Post("/get-access", getaccess.Handle)

    log.Fatal(app.Listen(":3000"))
}

Untuk memfungsikan endpoint tersebut, pertama siapkan satu fungsi khusus untuk membuat token JWT di file pkg/jwt/jwt.go:

package jwtutil

import (
    "time"

    "github.com/golang-jwt/jwt/v4"
)

const (
    SigMethod = "HS256"
    SigKey    = "2022terceS"
    Issuer    = "localhost"
    Audience  = "localhost"
)

// Sign creates a token from the specified claims.
func Sign(claims jwt.MapClaims, expiresIn time.Duration) string {
    claims["iss"] = Issuer
    claims["aud"] = Audience

    now := time.Now()
    claims["iat"] = now.Unix()
    claims["exp"] = now.Add(expiresIn).Unix()

    token := jwt.NewWithClaims(jwt.GetSigningMethod(SigMethod), claims)
    out, _ := token.SignedString([]byte(SigKey))

    return out
}

Di sini kita menggunakan signing method yang mudah dulu, yaitu HS256, di mana signing key yang digunakan sifatnya simetris: Key yang digunakan sama persis untuk signing dan verifikasi JWT.^[2]

Issuer = Pihak yang menerbitkan JWT. Audience = Pihak yang menggunakan JWT.
Jika dibuat sama, bisa bermaksud bahwa JWT diterbitkan dan digunakan sendiri. Meskipun itu bukan berarti JWT tersebut tidak akan berpindah tangan.
Setidaknya antara aplikasi server dan aplikasi client sudah termasuk dua pihak yang berbeda. JWT diterbitkan oleh server, kemudian "dipinjamkan" ke client, tetapi hanya server yang berhak untuk memverifikasinya.

Setelah itu buat fungsi handler yang dipasangkan ke endpoint /get-access itu tadi, yaitu di file pkg/getaccess/handler.go:

package getaccess

import (
    "github.com/gofiber/fiber/v2"
    "github.com/golang-jwt/jwt/v4"

    jwtutil "how-to-hybrid-auth/pkg/jwt"
    "how-to-hybrid-auth/pkg/store"
)

type (
    findUser struct {
        ID string `form:"id"`
    }

    accessResponse struct {
        AccessToken string `json:"access_token"`
    }
)

func Handle(c *fiber.Ctx) error {
    // Find user by ID.
    fUser := new(findUser)
    if err := c.BodyParser(fUser); err != nil {
        return err
    }

    users, err := store.Get("users")
    if err != nil {
        return err
    }

    user, ok := users[fUser.ID]
    if !ok {
        return c.SendStatus(fiber.StatusNotFound)
    }

    // Generate access token.
    accessClaims := jwt.MapClaims{
        "sub": fUser.ID,
    }

    for k, v := range user {
        accessClaims[k] = v
    }

    accessToken := jwtutil.Sign(accessClaims, 5*time.Minute)

    return c.JSON(accessResponse{accessToken})
}

Fungsi getaccess.Handle akan mencari user berdasarkan ID. Jika ada, maka ambil semua informasi dari user tersebut menjadi claim-claim JWT, kemudian operkan ke fungsi jwtutil.Sign untuk digabungkan dengan beberapa claim khusus.
Untuk demo ini, expiresIn (masa berlaku JWT) kita buat 5 menit saja, yang kira-kira cukup untuk melihat perubahan dari valid menjadi expired.
Terakhir dilakukan signing, sehingga menghasilkan token JWT.

Karena sampai di bagian ini kita sudah menggunakan beberapa dependency ekstra (3rd party packages), antara lain gofiber/fiber/v2 dan golang-jwt/jwt/v4, maka kita perlu panggil perintah berikut:

go mod tidy

Dengan begitu semua dependency tersebut menjadi tersedia untuk project ini.

Sekarang jalankan lagi aplikasi:

go run main.go

Itu menunjukkan bahwa aplikasi ini berjalan dengan Fiber, berupa server HTTP di port 3000.

Kita coba panggil endpoint yang dibuat tadi.
Tambahkan satu request di Postman seperti berikut:

Method: POST
URL: http://localhost:3000/get-access
Body: x-www-form-urlencoded
- id: { salah satu ID user }

Setelah klik Send, maka akan dapat jawaban seperti berikut:

{
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJsb2NhbGhvc3QiLCJleHAiOjE2NTI5NzA2MzYsImlhdCI6MTY1Mjk3MDMzNiwiaXNzIjoibG9jYWxob3N0IiwibmFtZSI6IkNhdHVyIiwicm9sZSI6IkRldmVsb3BlciIsInN1YiI6IjVoa2NSWmNyT1dUeGFlRmhxM0VkRCJ9.Qo70QaMH0NVo11i8u1uXgJssor1iAtGruXPiWG2PGF0"
}

3. Bedah Singkat Token JWT

Coba salin jawaban access_token di atas, atau yang Anda tes sendiri, ke website jwt.io.

Di situ kita bisa mengintip isi dari token, ada tiga bagian: Header, Payload dan Signature.

Bagian Header tidak saya jelaskan.
Bagian Payload berisi semua claim yang sudah disiapkan sebelumnya.
Bagian Signature digunakan untuk verifikasi. Bisa coba salin signing key yang didefinisikan di source code: "2022terceS".

Sekarang status di pojok kiri-bawah menjadi "Signature Verified".

Nah, token yang bisa di-parse sebelum diverifikasi seperti itu berarti dia termasuk jenis JWS (JSON Web Signature).
Jenis lainnya adalah JWE (JSON Web Encryption), yang isinya terenkripsi dan membutuhkan sebuah secret key untuk membukanya.

Jadi sebuah token JWT pasti berbentuk salah satu dari dua jenis tersebut.
Yang biasanya digunakan adalah JWS, berisi tiga bagian yang disebutkan di atas. Sedangkan JWE berisi lima bagian, dan salah satu metode enkripsinya adalah AES256-GCM.^[3]^[4]

4. JWT Middleware (Parse + Verifikasi)

Middleware untuk JWT termasuk salah satu yang dibuat oleh para maintainer Fiber, jadi kita tinggal memanfaatkannya saja.

Isi file pkg/authenticate/handler.go:

package authenticate

import (
    "github.com/gofiber/fiber/v2"
    jwtware "github.com/gofiber/jwt/v3"

    jwtutil "how-to-hybrid-auth/pkg/jwt"
)

func New() fiber.Handler {
    return jwtware.New(jwtware.Config{
        SigningMethod: jwtutil.SigMethod,
        SigningKey:    []byte(jwtutil.SigKey),
        ContextKey:    "auth",
    })
}

Supaya project mengenali dependency yang baru ditambahkan, panggil lagi perintah berikut:

go mod tidy

Signing method dan signing key yang digunakan adalah yang ditetapkan di file pkg/jwt/jwt.go.
Dengan konfigurasi minimal seperti di atas, maka otomatis dilakukan verifikasi:

Signature.
Expiration.

Jika butuh memverifikasi hal lain, misalnya Audience, maka harus ditulis secara custom:

package authenticate

import (
    "fmt"

    "github.com/gofiber/fiber/v2"
    jwtware "github.com/gofiber/jwt/v3"
    "github.com/golang-jwt/jwt/v4"

    jwtutil "how-to-hybrid-auth/pkg/jwt"
)

func New() fiber.Handler {
    return jwtware.New(jwtware.Config{
        SigningMethod: jwtutil.SigMethod,
        SigningKey:    []byte(jwtutil.SigKey),
        ContextKey:    "auth",
        SuccessHandler: func(c *fiber.Ctx) error {
            auth := c.Locals("auth").(*jwt.Token)
            claims := auth.Claims.(jwt.MapClaims)

            // Verify audience.
            if !claims.VerifyAudience(jwtutil.Audience, true) {
                msg := fmt.Sprintf("Invalid JWT audience. Expected: %s", jwtutil.Audience)
                return c.Status(fiber.StatusUnauthorized).SendString(msg)
            }

            return c.Next()
        },
    })
}

Middleware ini belum bisa digunakan jika belum ada endpoint yang dituju. Jadi kita langsung beranjak ke poin berikutnya.

5. Meminta Data Profil Pengguna

Buat fungsi handler di file pkg/getprofile/handler.go:

package getprofile

import (
    "github.com/gofiber/fiber/v2"
    "github.com/golang-jwt/jwt/v4"
)

var reservedClaims = map[string]struct{}{
    "iss": {},
    "aud": {},
    "exp": {},
    "nbf": {},
    "iat": {},
    "sub": {},
    "jti": {},
}

func Handle(c *fiber.Ctx) error {
    auth := c.Locals("auth").(*jwt.Token)
    claims := auth.Claims.(jwt.MapClaims)

    // Extract profile from JWT claims.
    profile := claims

    for k := range reservedClaims {
        delete(profile, k)
    }

    return c.JSON(profile)
}

Profil pengguna diekstrak dari claim-claim JWT, dengan mengeliminasi tujuh claim khusus (jika ada) yang disebut dengan reserved claims.^[5]

Dan ubah file main.go seperti berikut:

package main

import (
    "log"

    "github.com/gofiber/fiber/v2"

    "how-to-hybrid-auth/pkg/authenticate"
    "how-to-hybrid-auth/pkg/getaccess"
    "how-to-hybrid-auth/pkg/getprofile"
    "how-to-hybrid-auth/pkg/store"
)

func main() {
    // Seed some data.
    if err := store.Seed(); err != nil {
        panic(err)
    }

    // Create Fiber app.
    app := fiber.New()

    // External endpoints.
    app.Post("/get-access", getaccess.Handle)

    // JWT middleware.
    app.Use(authenticate.New())

    // Internal endpoints.
    app.Post("/get-profile", getprofile.Handle)

    log.Fatal(app.Listen(":3000"))
}

Jadi umumnya JWT middleware itu ditempatkan setelah endpoint-endpoint eksternal dan sebelum endpoint-endpoint internal.

Jalankan lagi aplikasi:

go run main.go

Kemudian ke Postman dan tambahkan satu request lagi:

Method: POST
URL: http://localhost:3000/get-profile
Body: none
Authorization: Bearer Token

Isikan Access Token ke kolom yang tersedia.

Jika token tidak valid atau sudah expired, maka akan dapat jawaban "Invalid or expired JWT".

Sedangkan jika valid, maka akan dapat jawaban seperti berikut:

{
    "name": "Catur",
    "role": "Developer"
}

Keterbatasan JWT

JWT memang dirancang untuk pertukaran informasi. Namun satu problem yang jelas adalah ketika misalnya data profil diubah dan kita butuh agar perubahan tersebut langsung berdampak terhadap penggunaan aplikasi, maka pada kondisi tersebut JWT tidak bisa diandalkan.
Jika untuk melihat perubahan itu harus melakukan penerbitan ulang JWT, maka sepertinya itu skenario yang terlalu memaksakan, tidak praktis.

Fakta yang ada di lapangan, oleh berbagai sistem penyedia identitas (identity provider), yaitu antara dua kemungkinan:

Token JWT bukan sebagai Access Token, melainkan hanya sebagai ID Token. Ini yang dilakukan oleh Apple.^[6]
Pihak provider menyediakan endpoint /userinfo dan butuh Access Token untuk memanggilnya. Ini yang dilakukan oleh Auth0.^[7]

Dalam kasus Apple, mereka tidak peduli terhadap perubahan profil pengguna dan cukup ID Token itu yang dijadikan patokan, selama masih valid.
Dari sisi aplikasi, bisa menetapkan durasi expiration, seperti yang ada di library albenik-go/apple-sign-in pada fungsi Client.ValidateCode.

Dalam kasus Auth0, Access Token yang digunakan untuk memanggil endpoint /userinfo bersifat opaque (tidak transparan). Artinya ketika aplikasi memperoleh Access Token, tidak untuk di-parse, sebab bukan JWT.

Userinfo: Tantangan dan Solusinya

Kita tahu bahwa urusan otentikasi dapat dikelola secara internal maupun eksternal.

Meskipun di atas sudah disebutkan tentang keterbatasan pada JWT dan keunggulan adanya endpoint /userinfo, tapi kadang kita dihadapkan pada tantangan ketika aplikasinya harus mendukung beberapa penyedia identitas, contohnya Google dan Facebook.

Google punya endpoint /userinfo.
Facebook punya endpoint /me.

Kalau hanya satu sumber data, kita bisa mengandalkannya. Tapi kalau lebih dari satu, itu juga menjadi masalah.
Mungkin endpoint tersebut hanya berguna untuk membantu pendaftaran pengguna, untuk mengisi profil di awal. Yang berarti aplikasi harus menyimpan data profil secara lokal.
Dalam kasus yang seperti ini, tidak ada bedanya antara penyedia identitas menggunakan endpoint /userinfo atau ID Token, karena hanya diakses sekali untuk masing-masing pengguna.

Jadi dapat diambil kesimpulan bahwa harusnya selalu ada data profil lokal aplikasi, baik itu otentikasinya secara internal maupun eksternal.

Sekarang untuk penyesuaian yang diperlukan di aplikasi demo kita:

Di file pkg/getaccess/handler.go, baris 35-49:

    _, ok := users[fUser.ID]
    if !ok {
        return c.SendStatus(fiber.StatusNotFound)
    }

    // Generate access token.
    accessClaims := jwt.MapClaims{
        "sub": fUser.ID,
    }

    accessToken := jwtutil.Sign(accessClaims, 5*time.Minute)

Di situ kita hanya membutuhkan informasi ID pengguna dan tidak menyertakan informasi lainnya untuk pembuatan Access Token.

Kemudian di file pkg/getprofile/handler.go:

package getprofile

import (
    "github.com/gofiber/fiber/v2"
    "github.com/golang-jwt/jwt/v4"

    "how-to-hybrid-auth/pkg/store"
)

var reservedClaims = map[string]struct{}{
    "iss": {},
    "aud": {},
    "exp": {},
    "nbf": {},
    "iat": {},
    "sub": {},
    "jti": {},
}

func Handle(c *fiber.Ctx) error {
    auth := c.Locals("auth").(*jwt.Token)
    claims := auth.Claims.(jwt.MapClaims)

    // Extract user ID from JWT claims.
    userID, ok := claims["sub"].(string)
    if !ok {
        return c.SendStatus(fiber.StatusNotFound)
    }

    // Find user by ID.
    users, err := store.Get("users")
    if err != nil {
        return err
    }

    user, ok := users[userID]
    if !ok {
        return c.SendStatus(fiber.StatusNotFound)
    }

    return c.JSON(user)
}

Di situ pertama kita memastikan bahwa JWT berisi claim "sub", yang itu adalah ID pengguna. Setelah itu kita mencari data pengguna berdasarkan ID tersebut.

Dengan begitu, hasil yang didapat akan selalu sesuai dengan data profil saat ini.

Jawaban pertama:

{
    "name": "Catur",
    "role": "Developer"
}

Jawaban kedua setelah data berubah:

{
    "name": "Catur",
    "role": "Maintainer"
}

Referensi

Bacaan/Tontonan Lanjutan

Bagaimana cara logout ketika menggunakan JWT: https://medium.com/devgorilla/how-to-log-out-when-using-jwt-a8c7823e8a6
Mengenal OpenID Connect: https://www.youtube.com/watch?v=6DxRTJN1Ffo&list=PLKCk3OyNwIzuD_jxWu-JddooM2yjX5q99&index=12