JWT and using JWT in Rails
Bài đăng này đã không được cập nhật trong 6 năm
Với sự xuất hiện của Single Page Applications(SPA) và mobile app, các API dần dần trở thành tiên phong trong quá trình phát triển web. Chúng ta thường phát triển các API để hỗ trợ cho các SPA và mobile app, vì vậy API chiếm vị trí quan trọng trong quá trình phát triển web. Token-based authentication là một trong những cơ chế authenticate được ưa chuộng nhất hiện nay. Tuy nhiên, các tokens dễ bị tấn công bằng nhiều cách khác nhau. Để khắc phục, một trong những cách để thực hiện, là hướng đến một giải pháp nhằm tạo ra các token có độ an toàn, bảo mật cao, tránh bị đánh cắp giữa các hệ thống khác nhau. JSON Web Tokens(JWT) đã được tạo ra nhằm xây dựng bộ tiêu chuẩn cơ sở cho việc handle và xác minh token làm cho quá trình trao đổi giữa các hệ thống khác nhau một cách an toàn.
WHAT IS JWT?
JWTs mang những thông tin(claims) thông qua JSON, vì vậy nó có tên là JSON Web Tokens. JWT là 1 tiêu chuẩn mở (RFC 7519) định nghĩa cách thức truyền tin an toàn giữa các thành viên bằng 1 đối tượng JSON. Thông tin này có thể được xác thực và đánh dấu tin cậy nhờ vào "chữ ký" của nó. Phần chữ ký của JWT sẽ được mã hóa lại bằng HMAC hoặc RSA. Nó được implement trên hầu hết những ngôn ngữ lập trình phổ biến hiện nay. Do vậy, ta có thể dễ dàng sử dụng và trao đổi trong các hệ thống được thực hiện trong các nền tảng khác nhau. JWT thực chất là 1 đoạn string, vì vậy chúng có thể dễ dàng được truyền thông qua URL hoặc HTTP header, chúng cũng mang theo những thông tin trong phần payload và signatures.
Anatomy of a JWT
Một JWT gồm 3 đoạn string được ngăn cách nhau bởi dấu "."
aaaaa.bbbbbbb.ccccccc
Header
Phần đầu tiên là header, phần thứ hai là payload và phần cuối là signatures.
Phần header gồm 2 thành phần:
- Kiểu của token, ví dụ như JWT (để phân biệt với JWS hay JWE)
- Thuật toán mã hóa sẽ dùng cho cái Token của chúng ta
{
"typ": "JWT",
"alg": "HS256"
}
Đoạn header trên sẽ được mã hóa bằng base64 và ta thu được kết quả phần header của JWT là:
aeyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload
Phần thứ hai của JWT là payload. Phần này sẽ mang những thông tin thú vị trong token, còn được gọi bằng cái tên khác là JWT Claims. Claims có 3 kiểu là: private, public và registered.
1, Registered Claims là những claims mà tên của chúng được khai báo nhưng không bắt buộc phải sử dụng, ví dụ như: iss, sub,aud...Là những thông tin được quy đinh ở trong IANA JSON Web Token Claims registry. Chúng bao gồm: Chú ý rằng các khóa của claim đều chỉ dài 3 ký tự vì mục đích giảm kích thước của Token:
- iss (issuer): tổ chức phát hành token
- sub (subject): chủ đề của token
- aud (audience): đối tượng sử dụng token
- exp (expired time): thời điểm token sẽ hết hạn
- nbf (not before time): token sẽ chưa hợp lệ trước thời điểm này
- iat (issued at): thời điểm token được phát hành, tính theo UNIX time
- jti: JWT ID
2, Private Claims là phần thông tin thêm dùng để truyền qua giữa các máy thành viên. Ví dụ:
{
"sub": "1234567890",
"name": "paduvi",
"admin": true
}
3, Public Claims chứa thông tin mà chúng ta tạo ra mỗi khi authenticate như: username, thông tin của user... Ví dụ:
“https://www.abc.com/jwt_claims/is_admin”: true
Chúng ta có thể tạo một payload mẫu như sau:
{
"iss": "sitepoint.com",
"name": "Devdatta Kane",
"admin": true
}
Và nó sẽ được mã hóa thành:
ew0KICAiaXNzIjogInNpdGVwb2ludC5jb20iLA0KICAibmFtZSI6ICJEZXZkYXR0YSBLYW5lIiwNCiAgImFkbWluIjogdHJ1ZQ0KfQ
Signatures
Phần thứ 3 của JWT và cũng là phần quan trọng nhất: signatures. Nó là phần chữ kí được tạo thành bằng cách kết hợp 3 thành phần: header, payload và secrets. Phần Header + Payload sẽ được tổng hợp và mã hóa lại bằng một giải thuật encode nào đó, càng phức tạp càng tốt như HMACSHA256 chẳng hạn với "secret" từ phía server-side secret. Giống như sau:
require "openssl"
require "base64"
var encodedString = Base64.encode64(header) + "." + Base64.encode64(payload);
hash = OpenSSL::HMAC.digest("sha256", "secret", encodedString)
Vì chỉ có server biết được secret. Nên không ai có thể giả mạo để giải mã được signatures.
Phần chữ ký của chúng ta sau khi được mã hóa sẽ trông như sau:
2b3df5c199c0b31d58c3dc4562a6e1ccb4a33cced726f3901ae44a04c8176f37
Bây giờ, chúng ta đã có đầy đủ 3 phần của JWT. Tổng hợp lại ta được:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ew0KICAiaXNzIjogInNpdGVwb2ludC5jb20iLA0KICAibmFtZSI6ICJEZXZkYXR0YSBLYW5lIiwNCiAgImFkbWluIjogdHJ1ZQ0KfQ.2b3df5c199c0b31d58c3dc4562a6e1ccb4a33cced726f3901ae44a04c8176f37
Using JWT in Rails
JWT có những thư viện trên hầu hết các nền tảng và Ruby cũng không phải ngoại lệ. Chúng ta sẽ tạo một Rails app đơn giản, sử dụng gem devise cho authenticate và gem JWT cho việc tạo và xác minh JWT tokens.
rails new jwt_on_rails
Sau khi app được khởi tạo xong, tạo Home controller để sử dụng cho việc check authenticate:
rails g controller Home index
Và thu được code của Home controller:
class HomeController < ApplicationController
def index
end
end
Map trong config/routes.rb:
Rails.application.routes.draw do
get 'home' => 'home#index'
end
Check server:
rails s
Tiếp theo, chúng ta add 2 gem devise và jwt vào Gemfile:
gem 'devise'
gem 'jwt'
Và tiến hành bundle:
bundle install
Tạo files config cho devise:
rails g devise:install
Tạo Devise User model và migrate database
rails g devise User
rake db:migrate
Đây là lúc chúng ta tích hợp JWT vào ứng dụng. Đầu tiên, tạo một lớp có tên JsonWebToken trong lib/json_web_token.rb. Lớp này sẽ chứa logic encode và decode cho JWT tokens:
class JsonWebToken
def self.encode(payload)
JWT.encode(payload, Rails.application.secrets.secret_key_base, 'HS256')
end
def self.decode(token)
return hIndifferentAccess.new(JWT.decode(token, Rails.application.secrets.secret_key_base, true, { algorithm: 'HS256' })[0])
rescue
nil
end
end
Ở đây, mình sử dụng giải thuật HS256(HMAC) để mã hóa, các bạn có thể dùng các giải thuật khác như: RSASSA, ECDSA, RSASSA-PSS...
Sau đó, add một khởi tạo cho việc include lớp JsonWebToken trong config/initializers/jwt.rb:
require 'json_web_token'
Bây giờ, chúng ta sẽ thêm một số method trong ApplicationController, chúng sẽ được sử dụng trong AuthenticateController:
class ApplicationController < ActionController::Base
attr_reader :current_user
protected
def authenticate_request!
unless user_id_in_token?
render json: { errors: ['Not Authenticated'] }, status: :unauthorized
return
end
@current_user = User.find(auth_token[:user_id])
rescue JWT::VerificationError, JWT::DecodeError
render json: { errors: ['Not Authenticated'] }, status: :unauthorized
end
private
def http_token
@http_token ||= if request.headers['Authorization'].present?
request.headers['Authorization'].split(' ').last
end
end
def auth_token
@auth_token ||= JsonWebToken.decode(http_token)
end
def user_id_in_token?
http_token && auth_token && auth_token[:user_id].to_i
end
end
Chúng ta đã add method authenticate_request! như là before_filter mỗi khi user credential. Tiếp theo chúng ta sẽ tạo AuthenticationController để handle tất cả authenticate request đến API Trong app/controllers/authentication_controller.rb:
class AuthenticationController < ApplicationController
def authenticate_user
user = User.find_for_database_authentication(email: params[:email])
if user.valid_password?(params[:password])
render json: payload(user)
else
render json: {errors: ['Invalid Username/Password']}, status: :unauthorized
end
end
private
def payload(user)
return nil unless user and user.id
{
auth_token: JsonWebToken.encode({user_id: user.id}),
user: {id: user.id, email: user.email}
}
end
end
Sau đó update routes:
Rails.application.routes.draw do
post 'auth_user' => 'authentication#authenticate_user'
get 'home' => 'home#index'
end
Add before_filter vào Home controller:
class HomeController < ApplicationController
before_filter :authenticate_request!
def index
render json: {'logged_in' => true}
end
end
Bây giờ, ta tạo một user mẫu để test cơ chế authenticate trong rails console:
rails c
User.create(email:'a@a.com', password:'changeme', password_confirmation:'changeme')
Khi bạn request đến server bằng lệnh:
curl http://localhost:3000/home
thì server sẽ trả về:
{"errors":["Not Authenticated"]}
Bây giờ, nếu ta authenticate lại và nhận một JWT cho những lần request tiếp theo:
curl -X POST -d email="a@a.com" -d password="changeme" http://localhost:3000/auth_user
Bạn sẽ nhận được một response thành công kèm JWT với thông tin user đã được add thêm:
{"auth_token":"token_nhận_được","user":{"id":1,"email":"a@a.com"}}
Sử dụng auth_token đó và request đến ./home:
curl --header "Authorization: Bearer token_nhận_được" http://localhost:3000/home
Và nhận được response thành công như sau:
{"logged_in":true}
Store token at client side
Các giải pháp để lưu trữ token ở phía client có một vài lựa chọn giúp bạn tìm được sự lựa chọn tốt nhât. Hãy điểm qua các option sau:
Option 1 - Web Storage (localStorage or sessionStorage)
Ưu điểm:
- Trình duyệt không tự động include bất kì cái gì từ web storage vào trong http request. Vì vậy nó không thể bị tấn công bằng CSRF
- Chỉ có thể được truy cập bằng javascript và chạy trên cùng domain.
- Cho phép truyền token vào HTTP(phần header Authorization với Bearer schema)
- Dễ dàng để pick các request cần authenticate
Nhược điểm
- Không thể được truy cập bằng javascript chạy trên 1 sub-domain(một giá trị được viết trên example.com không thể được đọc trên sub.domain.com)
- Có khả năng bị tấn công XSS
- Để thực hiện authenticate, bạn chỉ có thể sử dụng trình duyệt hay các thư viện API cho phép bạn custome request(truyền token vào Authorization header)
Usage
Sử dụng localStorage hoặc sessionStorage để lưu và get token khi request được thực hiện:
localStorage.setItem('token', 'asY-x34SfYPk'); // write
console.log(localStorage.getItem('token')); // read
Option 2 - HTTP-only cookie
Ưu điểm:
- Không bị tấn công bằng XSS
- Trình duyệt tự động include token vào request
- Cookie có thể được tạo tại main domian và được sử dụng ở cả các sub-domain
Nhược điểm:
- Có nguy cơ bị tấn công bằng CSRF
- Cần cân nhắc và luôn lưu ý việc sử dụng cookie tại các sub-domain
- Việc chọn riêng các request cần include cookie hoàn toàn có thể làm được nhưng dễ gây lộn xộn
- Bạn có thể gặp phải một số vấn đề giữa những ràng buộc của trình duyệt và cookie
- Phía server cần validate cookie cho việc authenticate chứ không phải là Authorization header
Usage
Bạn không cần làm gì tại client side vì trình duyệt sẽ tự động làm tất cả
Option 3 - Javascript accessible cookie ignored by server-side
Ưu điểm:
- Không bị tấn công bằng CSRF (vì nó bị ignore bởi server)
- Cookie có thể được tạo tại main domian và được sử dụng ở cả các sub-domain
- Cho phép truyền token vào HTTP(phần header Authorization với Bearer schema)
- Dễ dàng để pick các request cần được authenticate
Nhược điểm:
- Có thể bị tấn công bằng XSS
- Nếu không cẩn thận thì trình duyệt sẽ tự động include cookie vào những request không cần thiết
- Để thực hiện authenticate, bạn chỉ có thể sử dụng trình duyệt hay các thư viện API cho phép bạn custome request(truyền token vào Authorization header)
Usage
Sử dụng document.cookie để lưu trữ cũng như get token khi request được thực hiện:
document.cookie = "token=asY-x34SfYPk"; // write
console.log(document.cookie); // read
Nói chung, option 1 nên được lựa chọn và sử dụng vì:
- Khi bạn tạo một web app, bạn cần deal với XSS, luôn luôn độc lập với nơi lưu trữ token
- Không sử dụng cookie để authenticate, do vậy sẽ không lo một cuộc tấn công CSRF
Tham khảo: https://jwt.io/introduction/ https://www.sitepoint.com/introduction-to-using-jwt-in-rails/ https://github.com/jwt/ruby-jwt https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
All rights reserved
