Cách đăng nhập vào nhiều trang WordPress chỉ bằng một lần (Single Sign-On to Multiple)

Khi làm việc với các tổ chức lớn, việc họ có nhiều trang WordPress là điều có thể xảy ra. Tôi thường được hỏi liệu có khả năng cho người dùng đăng nhập vào một trang web chỉ một lần nhưng có thể truy cập vào nhiều trang WordPress hay không.

Về cơ bản, họ đang tìm cách chia sẻ thông tin phiên đăng nhập qua nhiều trang web.

Chúng ta gọi điều này là Đăng nhập Một lần (Single Sign-On hay SSO).

Dưới đây là cách thực hiện Đăng nhập Một lần cho WordPress, nơi người dùng chỉ cần đăng nhập một lần rồi có thể truy cập vào nhiều trang web mà không cần phải đăng nhập lại.

Trước khi chúng ta đi vào các giải pháp, chúng ta nên hiểu trước cách người dùng đăng nhập vào WordPress.

Trong bài viết này, chúng ta sẽ xem xét hai loại tương tác của người dùng với trang web – người dùng chưa đăng nhập và người dùng đã đăng nhập.

Người dùng chưa đăng nhập, thường được gọi là “khách”, có thể điều hướng quanh các trang công cộng của trang web của bạn mà không cần nhập bất kỳ thông tin nhận diện nào và họ không cần quyền truy cập đặc biệt để làm điều đó.

Khi người dùng cần thực hiện các hoạt động khác như chỉnh sửa nội dung, mua hàng, thanh toán hoặc tham gia các khóa học, chúng tôi muốn giữ họ chịu trách nhiệm và đảm bảo rằng họ chỉ có thể thực hiện những gì họ được phép làm.

Vì vậy, chúng tôi cho phép họ đăng nhập vào trang web của chúng tôi, truy cập vào nội dung cao cấp mà các khách truy cập thông thường không thể truy cập.

Sau khi người dùng đăng nhập, chúng tôi muốn họ có thể điều hướng quanh trang WordPress của chúng tôi hoặc bảng điều khiển thành viên của họ mà không cần phải nhập lại thông tin đăng nhập trên mỗi lần làm mới trang.

Chúng tôi gọi trạng thái này là một phiên (session).

Phiên đăng nhập

Một phiên đăng nhập thường kéo dài cho đến khi người dùng đăng xuất, đóng tất cả các tab trình duyệt liên quan hoặc nếu phiên đã không hoạt động trong một thời gian nhất định. WordPress lưu trữ thông tin phiên đăng nhập trong ba cookie. Các cookie này là các tệp dữ liệu nhỏ được lưu trữ trên máy tính của bạn bởi trình duyệt. Cookie wordpress_[hash] lưu trữ thông tin đăng nhập, cookie wordpress_logged_in_[hash] xác định khi nào bạn đã đăng nhập, và cookie wp-settings-{time}-[UID] lưu các tùy chọn trong khu vực quản trị.

Hoặc để xem chi tiết cookie nâng cao hơn, hãy mở Công cụ dành cho nhà phát triển Chrome <ctrl>+<shift>+i và nhấp vào tab Ứng dụng, sau đó nhấp vào Cookie.

Cookie xác thực của WordPress

Cookie xác thực được WordPress sử dụng khi bạn đăng nhập lưu trữ một số dữ liệu quan trọng. Cookie này giúp duy trì phiên đăng nhập và xác thực người dùng khi truy cập vào trang web. Nội dung của cookie bao gồm thông tin về phiên đăng nhập, người dùng, và các quyền truy cập. Việc này đảm bảo rằng người dùng không cần phải nhập lại thông tin đăng nhập trên mỗi trang hoặc khi truy cập khu vực quản trị.

ID của Cookie

ID của cookie xác thực trong WordPress được định nghĩa trong tệp wp-includes/default-constants.php. Nó bắt đầu với “wordpress_” và theo sau là một chuỗi hash của URL trang web. Giá trị tên người dùng được lấy trực tiếp từ cơ sở dữ liệu và là ID được gán cho thông tin đăng ký của bạn khi lưu trữ trong bảng wp_users. Mã trong tệp này định nghĩa các biến AUTH_COOKIE và COOKIEHASH, xác định cách thức cookie xác thực hoạt động trong WordPress.

if ( !defined('AUTH_COOKIE') )
		define('AUTH_COOKIE', 'wordpress_' . COOKIEHASH);

if ( !defined( 'COOKIEHASH' ) ) {
	$siteurl = get_site_option( 'siteurl' );
	if ( $siteurl )
		define( 'COOKIEHASH', md5( $siteurl ) );
	else
		define( 'COOKIEHASH', '' );
}

Giá trị lưu trong Cookie

Bên trong cookie, giá trị đầu tiên là tên người dùng đã đăng nhập vào WordPress. Giá trị thứ hai là Thời gian hết hạn (Expiry Time), được lưu dưới dạng Unix timestamp, chứa ngày và giờ mà cookie sẽ hết hạn. Thời gian hết hạn được đặt khi cookie được tạo và mặc định là 2 ngày. Nếu bạn chọn “Remember Me” khi đăng nhập, thời gian hết hạn sẽ là 14 ngày. Mã liên quan nằm trong tệp wp-includes/pluggable.php trong hàm wp_set_auth_cookie.

if ( $remember ) {
	/**
	 * Filters the duration of the authentication cookie expiration period.
	 *
	 * @since 2.8.0
	 *
	 * @param int  $length   Duration of the expiration period in seconds.
	 * @param int  $user_id  User ID.
	 * @param bool $remember Whether to remember the user login. Default false.
	 */
	$expiration = time()   apply_filters( 'auth_cookie_expiration', 14 * DAY_IN_SECONDS, $user_id, $remember );
	/*
	 * Ensure the browser will continue to send the cookie after the expiration time is reached.
	 * Needed for the login grace period in wp_validate_auth_cookie().
	 */
	$expire = $expiration   ( 12 * HOUR_IN_SECONDS );
} else {
	/** This filter is documented in wp-includes/pluggable.php */
	$expiration = time()   apply_filters( 'auth_cookie_expiration', 2 * DAY_IN_SECONDS, $user_id, $remember );
	$expire = 0;
}

Sau thời gian này, cookie sẽ không còn hợp lệ và bạn sẽ được yêu cầu đăng nhập lại vào trang web.

Token
Phiên bản WordPress 4 và các phiên bản cao hơn thêm một giá trị token vào cookie để tăng cường bảo mật.

Token được tạo ra từ một tập hợp các hàm nhằm liên kết tốt hơn các cookie phiên với một người dùng cụ thể và đảm bảo rằng chúng hết hạn đúng cách.

Hash
Hash là phần thú vị nhất của giá trị cookie.

Cho đến phần này, ID cookie, tên người dùng và thời gian hết hạn đều có thể dự đoán được và có thể bị các hacker tinh vi tính toán.

Việc cho phép hacker đoán các giá trị là không tốt cho bảo mật, vì lý do đó mà giá trị hash tồn tại.

Để thêm một chút ngẫu nhiên vào cookie, giá trị được tính từ một phần con của giá trị hash mật khẩu đăng nhập của người dùng được lưu trữ trong bảng wp_user của cơ sở dữ liệu.

WordPress Lưu Trữ Mật Khẩu Người Dùng Như Thế Nào?

WordPress không lưu trữ mật khẩu của người dùng trong cơ sở dữ liệu, không phải dưới dạng văn bản thuần túy hoặc mã hóa.

Một giá trị hash của mật khẩu được tạo ra khi người dùng đăng ký và giá trị đó được lưu trữ trong bảng người dùng.

Khi một người dùng nhập mật khẩu của họ vào màn hình đăng nhập, WordPress sẽ hash giá trị mật khẩu đó và so sánh nó với giá trị được lưu trữ trong cơ sở dữ liệu.

Mặc định, WordPress sử dụng hàm MD5 của PHP để tạo ra hash mật khẩu của người dùng.

WordPress cho phép các nhà phát triển tùy chỉnh hệ thống đăng nhập và đăng ký, bao gồm cả cách xử lý mật khẩu, đó là lý do tại sao loại hàm mã hóa đang được sử dụng được thêm vào trước giá trị hash mật khẩu đã lưu trữ.

Trong trường hợp trên, $P$B đề cập đến hàm MD5 của PHP.

Tạo Giá Trị Hash Cookie
Cụ thể, các ký tự từ vị trí 8 đến 12 của giá trị hash mật khẩu của người dùng được sử dụng làm khóa bí mật để tạo ra sự ngẫu nhiên trong giá trị hash cookie.

Việc này được thực hiện bởi hàm wp_generate_auth_cookie trong tệp wp-includes/pluggable.php.

function wp_generate_auth_cookie( $user_id, $expiration, $scheme = 'auth', $token = '' ) {
	$user = get_userdata($user_id);
	if ( ! $user ) {
		return '';
	}

	if ( ! $token ) {
		$manager = WP_Session_Tokens::get_instance( $user_id );
		$token = $manager->create( $expiration );
	}

	$pass_frag = substr($user->user_pass, 8, 4);

	$key = wp_hash( $user->user_login . '|' . $pass_frag . '|' . $expiration . '|' . $token, $scheme );

	// If ext/hash is not present, compat.php's hash_hmac() does not support sha256.
	$algo = function_exists( 'hash' ) ? 'sha256' : 'sha1';
	$hash = hash_hmac( $algo, $user->user_login . '|' . $expiration . '|' . $token, $key );

	$cookie = $user->user_login . '|' . $expiration . '|' . $token . '|' . $hash;

	/**
	 * Filters the authentication cookie.
	 *
	 * @since 2.5.0
	 * @since 4.0.0 The `$token` parameter was added.
	 *
	 * @param string $cookie     Authentication cookie.
	 * @param int    $user_id    User ID.
	 * @param int    $expiration The time the cookie expires as a UNIX timestamp.
	 * @param string $scheme     Cookie scheme used. Accepts 'auth', 'secure_auth', or 'logged_in'.
	 * @param string $token      User's session token used.
	 */
	return apply_filters( 'auth_cookie', $cookie, $user_id, $expiration, $scheme, $token );
}

Dòng 9 tạo ra một phiên bản token quản lý giúp quản lý phiên người dùng và thời gian hết hạn của cookie.

Chúng ta có thể thấy dòng 12 lấy các ký tự từ vị trí 8 đến 12 của giá trị hash mật khẩu người dùng từ cơ sở dữ liệu.

Dòng 14 tạo ra một khóa bí mật sử dụng các ký tự ngẫu nhiên từ dòng 12.

Sau đó, dòng 18 tạo ra phần giá trị hash ngẫu nhiên của cookie.

Cuối cùng, dòng 20 thiết lập giá trị cookie hoàn chỉnh sử dụng tên người dùng, thời gian hết hạn và các giá trị hash.

Vì mỗi cookie phiên được liên kết với một người dùng, sử dụng dữ liệu từ bảng wp_users của WordPress cho trang web đó, mỗi cookie được thiết kế cụ thể để chỉ được sử dụng cho việc đăng nhập vào trang web đó.

Bảo Vệ Các Salt Của Bạn
Khi WordPress tạo hash cho các mục đích bảo mật như cookies, nó sử dụng các khóa SALT tìm thấy trong tệp wp-config.php của bạn để tạo ra sự ngẫu nhiên bổ sung.

Tập hợp khóa SALT mặc định trông như thế này:

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Đề Xuất Bảo Mật
Rất được khuyến khích là bạn nên truy cập liên kết trong phần bình luận về các khóa SALT để tạo ra một bộ mới.

Sao chép và dán các giá trị mới vào tệp wp-config.php, thay thế các giá trị mặc định.

Kết Luận Về Cookies
Cookies không thể chuyển giao giữa các trang WordPress khác nhau, và đó là lý do chúng ta cần triển khai giải pháp Đăng nhập Một lần (SSO).

WordPress Multisite
Một cài đặt multisite hoạt động hơi khác so với các trang WordPress đơn và có thể thực hiện SSO nếu quản trị viên của từng trang con có cùng địa chỉ email với quản trị viên mạng chính.

Nhưng điều này chỉ hoạt động cho quản trị viên mạng chính, không phải cho người dùng trang web thông thường.

Một lần nữa, chúng ta cần tìm một giải pháp cho Đăng nhập Một lần ngay cả trong môi trường multisite.

Phương Pháp The Hammer and Peg Approach

Tôi không khuyến nghị phương pháp này, nhưng tôi sẽ mô tả nó để tham khảo, phòng khi có ai đó đề cập đến trong các bình luận sau này.

Trong các phần trước, chúng ta đã thấy rằng cookies phiên được liên kết với thông tin đăng nhập của người dùng, mà WordPress lưu trữ trong bảng wp_users của cơ sở dữ liệu.

Vậy nếu chúng ta có thể tạo ra nhiều trang WordPress chia sẻ các bảng wp_users và wp_usermeta chung thì sao?

Điều này có thể thực hiện được nhưng không phải là giải pháp tốt nhất.

Giống như cài đặt multisite, phương pháp này yêu cầu các trang WordPress chia sẻ của bạn đều lưu trữ thông tin trong cùng một cơ sở dữ liệu.

Điều này hạn chế các tùy chọn của bạn để cải thiện hiệu suất cơ sở dữ liệu cho một trang duy nhất.

Cũng có một điều cần lưu ý là các trang phải được cài đặt trên cùng một miền hoặc miền con để điều này hoạt động.

Tôi sẽ không mô tả quá trình này chi tiết ở đây vì nó đã được phác thảo từng bước trong một bài viết trên Stack Exchange từ năm 2017.

Tóm lại, bạn cài đặt mỗi trang của mình vào cùng một cơ sở dữ liệu với một tiền tố cơ sở dữ liệu khác nhau, nhớ không đăng nhập vào bất kỳ trang nào trong số này cho đến khi bạn hoàn tất toàn bộ quá trình.

Khi cài đặt từng trang, bạn chỉ định đường dẫn cookie, miền và phương pháp hash trong tệp wp-config.php, ghi đè các chức năng mặc định. Xem dưới đây.

define('COOKIE_DOMAIN', '.xyz.com');
define('COOKIEPATH', '/');
define('COOKIEHASH', md5('xyz.com'));

Sau mỗi lần cài đặt trang, bạn phải sao chép một hàm vào tất cả các trang để đồng bộ hóa tất cả dữ liệu người dùng và meta người dùng về một trang mà bạn đã chọn làm trang “chính”, nơi sẽ thực hiện việc đăng nhập.

Sau khi dữ liệu người dùng đã được di chuyển, bạn sẽ xóa các bảng wp_user và wp_usermeta từ các trang còn lại.

Bạn sẽ có nhiều trang chia sẻ các bảng wp_user và wp_usermeta chung.

Quá trình thực hiện điều này với các trang hiện có phức tạp hơn và tôi khuyên bạn nên đọc bài viết trên Stack Exchange để hiểu rõ hơn về điều đó.

SSO Hoạt Động Như Thế Nào?
Cuối cùng, hãy cùng nói về Đăng nhập Một lần (SSO).

Để hai hoặc nhiều trang khác nhau cho phép người dùng sử dụng Đăng nhập Một lần, một trang phải được chỉ định làm trang chính, hoặc máy chủ, và các trang khác là khách hàng.

Trang chính là trang quản lý phiên người dùng, bao gồm thông tin cookie mà trình duyệt cần.

Nếu một người dùng cố gắng đăng nhập vào một trang khách hàng, trang khách hàng đó sẽ cần chuyển thông tin đó đến trang chính để xác thực và chờ nhận dữ liệu phiên người dùng đã được xác thực để cho phép người dùng đăng nhập.

Để SSO hoạt động, do đó, dữ liệu đăng nhập và phiên phải được truyền và xử lý giữa các trang khác nhau.

Tất cả phải hoạt động một cách an toàn và liền mạch.

Đây là mô hình máy chủ-khách và có ba phương pháp tiêu chuẩn ngành để truyền dữ liệu xác thực giữa khách hàng và máy chủ cho SSO.

Chúng được gọi là SAML, OAuth và OpenID. Hãy cùng xem xét chúng bây giờ.

SAML Là Gì?
Security Assertion Markup Language (SAML, phát âm là sam-el) là một tiêu chuẩn mở để trao đổi dữ liệu xác thực và ủy quyền giữa các bên.

SAML sử dụng cấu trúc dữ liệu XML để trao đổi thông tin.

Một số từ viết tắt mà SAML sử dụng:

• IdP – Identity Provider
  Dịch vụ lưu trữ thông tin đăng nhập.

• SP – Service Provider
  Dịch vụ yêu cầu kiểm tra ID.

Lần đầu tiên phát hành vào năm 2002, SAML đã được sử dụng một thời gian khá lâu.

Vào năm 2005, phiên bản 2.0 được phát hành với chức năng và bảo mật được cải thiện nhiều và nó không thay đổi nhiều kể từ đó.

SAML cung cấp giải pháp để cho phép nhà cung cấp danh tính và nhà cung cấp dịch vụ tồn tại riêng biệt với nhau.

Điều này tập trung hóa quản lý người dùng và cung cấp quyền truy cập vào các giải pháp Phần mềm như một Dịch vụ (SaaS).

SAML Hoạt Động Như Thế Nào?
Khi một người dùng cố gắng đăng nhập vào một ứng dụng hỗ trợ SAML, nhà cung cấp dịch vụ yêu cầu ủy quyền từ nhà cung cấp danh tính liên kết.

Nhà cung cấp danh tính xác thực thông tin đăng nhập của người dùng và sau đó trả lại ủy quyền cho người dùng cho nhà cung cấp dịch vụ.

Người dùng hiện có thể sử dụng ứng dụng.

LDAP, Microsoft Active Directory và RazDC đều là các ví dụ về nhà cung cấp danh tính lưu trữ thông tin đăng nhập bảo mật của người dùng.

Salesforce và Amazon Web Services là các ví dụ về nhà cung cấp dịch vụ yêu cầu quyền truy cập sử dụng SAML từ một nhà cung cấp danh tính để đăng nhập người dùng.

Vì SAML sử dụng XML để chia sẻ dữ liệu xác thực nên nó phổ biến với các tổ chức lớn và doanh nghiệp.

Dưới đây là một ví dụ về một câu lệnh SAML XML (assertion):

<saml:Assertion
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
   Version="2.0"
   IssueInstant="2004-12-05T09:22:05Z">
   <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
   <ds:Signature
     xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
   <saml:Subject>
     <saml:NameID
       Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
       3f7b3dcf-1674-4ecd-92c8-1544f346baf8
     </saml:NameID>
     <saml:SubjectConfirmation
       Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
       <saml:SubjectConfirmationData
         InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
         Recipient="https://sp.example.com/SAML2/SSO/POST"
         NotOnOrAfter="2004-12-05T09:27:05Z"/>
     </saml:SubjectConfirmation>
   </saml:Subject>
   <saml:Conditions
     NotBefore="2004-12-05T09:17:05Z"
     NotOnOrAfter="2004-12-05T09:27:05Z">
     <saml:AudienceRestriction>
       <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
     </saml:AudienceRestriction>
   </saml:Conditions>
   <saml:AuthnStatement
     AuthnInstant="2004-12-05T09:22:00Z"
     SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
     <saml:AuthnContext>
       <saml:AuthnContextClassRef>
         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
       </saml:AuthnContextClassRef>
     </saml:AuthnContext>
   </saml:AuthnStatement>
   <saml:AttributeStatement>
     <saml:Attribute
       xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
       x500:Encoding="LDAP"
       NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
       Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
       FriendlyName="eduPersonAffiliation">
       <saml:AttributeValue
         xsi:type="xs:string">member</saml:AttributeValue>
       <saml:AttributeValue
         xsi:type="xs:string">staff</saml:AttributeValue>
     </saml:Attribute>
   </saml:AttributeStatement>
 </saml:Assertion>

OAuth Là Gì?
OAuth cung cấp cho các khách hàng quyền truy cập “ủy quyền an toàn” vào tài nguyên máy chủ thay mặt cho chủ sở hữu tài nguyên.

Đây là một tiêu chuẩn mới hơn được đồng phát triển bởi Google và Twitter để cho phép việc đăng nhập trên internet diễn ra một cách thuận tiện hơn.

Bạn có thể đã sử dụng OAuth mà không nhận ra.

Khi một trang web yêu cầu bạn đăng nhập bằng ID Google hoặc Facebook của bạn, đó chính là OAuth hoạt động trong nền.

Phiên bản 1.0 được phát hành vào năm 2006 và phiên bản an toàn hơn 2.0 được phát hành vào năm 2012.

Phiên bản mới cung cấp các luồng ủy quyền cụ thể cho các ứng dụng web, ứng dụng máy tính để bàn, điện thoại di động và thiết bị thông minh.

OAuth sử dụng cấu trúc dữ liệu JSON để trao đổi thông tin.

OAuth Hoạt Động Như Thế Nào?
OAuth là một giao thức ủy quyền, chứ không phải giao thức xác thực.

Việc sử dụng OAuth riêng lẻ như một phương pháp xác thực có thể được gọi là “xác thực giả”.

Các sơ đồ sau đây làm nổi bật sự khác biệt giữa việc sử dụng OpenID (được thiết kế đặc biệt như một giao thức xác thực) và OAuth cho xác thực.

Với OAuth, bạn không cần nhập ID người dùng và mật khẩu của mình. Thay vào đó, bạn đăng nhập vào nhà cung cấp danh tính (như Google) và sau đó có một thông báo hình ảnh yêu cầu bạn ủy quyền cho ứng dụng hoặc dịch vụ mà bạn muốn đăng nhập thông qua nhà cung cấp danh tính.

Đây là một hệ thống dựa trên giao diện hình ảnh, hiển thị một nút để xác nhận rằng nhà cung cấp danh tính có thể thực hiện các hành động thay mặt cho người dùng.

Vì vậy, với OAuth, bạn không bao giờ có thể chắc chắn 100% rằng người dùng thực sự là người đang yêu cầu “key to your home” và do đó nó được coi là kém an toàn hơn so với SAML (hoặc OpenID).

OpenID là gì?

OpenID là một khung làm việc sử dụng OAuth2 cho việc ủy quyền.

Nó được phát hành vào năm 2005, sự chấp nhận bởi Symantec và Microsoft vào năm 2007 đã thúc đẩy sự phổ biến của nó.

“OpenID Connect” là tên của phiên bản hiện tại.

Một số từ viết tắt mà OpenID sử dụng:

Relying Party (Bên phụ thuộc) Dịch vụ yêu cầu xác minh danh tính.

OpenID hoạt động như thế nào? Nó cho phép bạn chọn một nhà cung cấp danh tính (chẳng hạn như Google) làm nhà cung cấp danh tính OpenID của bạn.

Nếu một trang web hỗ trợ OpenID, bạn có thể đăng nhập bằng thông tin đăng nhập từ nhà cung cấp danh tính mà bạn đã chọn, do đó bạn chỉ cần nhớ một bộ thông tin bảo mật duy nhất.

Bạn chỉ cần cung cấp mật khẩu của mình cho nhà cung cấp OpenID, sau đó nhà cung cấp của bạn sẽ xác nhận với các trang web bạn truy cập rằng bạn đúng là người thật.

Không có trang web nào ngoài nhà cung cấp của bạn nhìn thấy mật khẩu của bạn và bạn có thể chọn dữ liệu nào mà bên tin cậy có quyền truy cập.

Authentication vs. Authorisation (xác thực và ủy quyền)

Về các hệ thống đăng nhập, “xác thực” và “ủy quyền” dường như có thể hoán đổi cho nhau.

Thoạt nhìn, chúng có vẻ có cùng ý nghĩa, nhưng trong bối cảnh đăng nhập người dùng, chúng rất khác nhau.

Xác thực trong bối cảnh người dùng truy cập vào một ứng dụng cho ứng dụng biết người dùng hiện tại là ai và liệu họ có mặt bằng cách nhập thông tin đăng nhập bảo mật của mình hay không.

Vì vậy, xác thực liên quan đến người dùng và sự hiện diện của họ với ứng dụng.

Bạn thực sự cần phải tiến hành xác thực trước khi cho phép người dùng truy cập vào thông tin cá nhân của họ.

Điều này đảm bảo rằng họ đúng là người mà họ nói khi truy cập các trang web và ứng dụng.

Ủy quyền không thể cung cấp sự đảm bảo này, cũng không cho biết cách người dùng đã chứng minh sự hiện diện của họ hay thậm chí liệu họ có còn ở đó hay không.

Ủy quyền dựa trên một token đáng tin cậy mà tại một thời điểm nào đó trong quá khứ, người dùng đã cho phép kết nối đáng tin cậy đó được sử dụng.

Vì vậy, chúng ta có xu hướng thấy và sử dụng ủy quyền cho các ứng dụng khách hoặc các dịch vụ thường xuyên truy cập vào các hệ thống khác, nhưng không phải cho con người thật.

SAML vs. OAuth

OAuth sử dụng một phương pháp tương tự như SAML để chia sẻ thông tin đăng nhập.

SAML cung cấp khả năng kiểm soát chính xác hơn cho các doanh nghiệp để giữ cho các lần đăng nhập SSO (Single Sign-On) của họ an toàn hơn, trong khi OAuth lại phù hợp hơn với thiết bị di động và sử dụng JSON.

Bởi vì OAuth là một hệ thống dựa trên hình ảnh và không yêu cầu người dùng nhập thông tin đăng nhập, nó được coi là kém an toàn hơn và có nguy cơ bị tấn công phishing.

Vào tháng 4-5 năm 2017, khoảng một triệu người dùng Gmail đã trở thành mục tiêu của một cuộc tấn công phishing dựa trên OAuth, khi nhận được một email giả mạo là từ đồng nghiệp, nhà tuyển dụng hoặc bạn bè, muốn chia sẻ một tài liệu trên Google Docs.

Những người nhấp vào liên kết trong email sẽ được chuyển hướng đến trang đăng nhập và cho phép một chương trình của bên thứ ba có thể gây hại gọi là “Google Apps” truy cập vào “tài khoản email, danh bạ và tài liệu trực tuyến” của họ.

Trong vòng “khoảng một giờ”, cuộc tấn công phishing đã bị Google ngăn chặn, và Google khuyên những người đã cho phép “Google Apps” truy cập vào email của họ nên thu hồi quyền truy cập đó và thay đổi mật khẩu của họ.

– Nguồn Wikipedia