---
description: >-
  Nếu bạn không muốn tìm hiểu quá rõ về Spring Security mà đơn giản là chỉ muốn
  sử dụng nó trong project, thì đây là thứ bạn cần và có thể bỏ qua các chủ đề
  phía sau trong mục Spring Security.
---

# Đơn giản hoá Spring Security

## Hiểu cơ bản về bảo mật

### Trong bất kỳ hệ thống nào:&#x20;

Bạn có các tài nguyên&#x20;

* Một REST API, Ứng dụng Web, Cơ sở dữ liệu, Tài nguyên trên đám mây, ...

&#x20;Bạn có các danh tính&#x20;

*   Các danh tính cần truy cập vào tài nguyên và thực hiện các hành động&#x20;

    Ví dụ: Thực hiện một cuộc gọi REST API, Đọc/sửa dữ liệu trong cơ sở dữ liệu&#x20;

Key question

* Làm thế nào để xác định người dùng?&#x20;
* Làm thế nào để cấu hình các tài nguyên mà họ có thể truy cập và các hành động được cho phép?

### Authentication (người dùng có đúng không?)&#x20;

* UserId/mật khẩu (Bạn nhớ gì?)&#x20;
* Nhận dạng sinh trắc học (Bạn sở hữu cái gì?)&#x20;

### Authorization (họ có quyền truy cập không?)&#x20;

* Người dùng XYZ chỉ có thể đọc dữ liệu
* Người dùng ABC có thể đọc và cập nhật dữ liệu&#x20;

## Hiểu các nguyên tắc bảo mật quan trọng

{% hint style="info" %}
_**Người Mỹ có câu tục ngữ:** "The chain is as strong as its weakest link" - Một sợi dây xích chỉ khỏe bằng mắt xích yếu nhất của nó_
{% endhint %}

Một lỗi bảo mật nhỏ khiến ứng dụng với kiến trúc mạnh mẽ trở nên dễ tổn thương

### 6 Nguyên tắc xây dựng hệ thống an toàn

<details>

<summary>Không tin tưởng vào bất cứ điều gì</summary>

Xác minh mỗi yêu cầu&#x20;

Xác minh từng mảnh dữ liệu hoặc thông tin được đưa vào hệ thống

</details>

<details>

<summary>Giao cho ít quyền nhất</summary>

Bắt đầu thiết kế hệ thống với yêu cầu bảo mật trong tâm trí&#x20;

Có một cái nhìn rõ ràng về vai trò và quyền truy cập của người dùng&#x20;

Giao cho ít quyền nhất có thể ở mọi cấp độ&#x20;

* Ứng dụng&#x20;

- Cơ sở hạ tầng (cơ sở dữ liệu + máy chủ + ...)

</details>

<details>

<summary>Đảm bảo quyền kiểm soát đầy đủ</summary>

Lâu đài thời Trung cổ được bảo vệ như thế nào? &#x20;

* Ai cũng phải đi qua một cổng chính

Áp dụng một bộ lọc bảo mật được thực hiện tốt. Kiểm tra vai trò và quyền truy cập của từng người dùng.

</details>

<details>

<summary>Có phòng thủ đa lớp (Defense in Depth)</summary>

Nhiều cấp độ bảo mật&#x20;

* Vận chuyển, Mạng, Cơ sở hạ tầng&#x20;

- &#x20;Hệ điều hành, Ứng dụng, ..

</details>

<details>

<summary>Có tính kinh tế của cơ chế (Economy of Mechanism)</summary>

Kiến trúc bảo mật nên đơn giản&#x20;

Hệ thống đơn giản dễ bảo vệ hơn

</details>

<details>

<summary>Đảm bảo tính mở của thiết kế (Openness of Design)</summary>

Dễ nhận ra và khắc phục các lỗi bảo mật&#x20;

Trái ngược với quan niệm sai lầm "Bảo mật bằng sự thâm sâu"

</details>

## Bắt đầu với Spring Security

Bảo mật là ưu tiên HÀNG ĐẦU cho các doanh nghiệp ngày nay!&#x20;

Dự án bảo mật phổ biến nhất trong hệ sinh thái Spring là gì?

**Spring Security: Bảo vệ ứng dụng web, REST API và microservices**

**Spring Security có thể khó khăn khi bắt đầu Filter Chain (chuỗi bộ lọc)**

* Quản lý xác thực (Authentication managers)
* Nhà cung cấp xác thực (Authentication providers)

Tuy nhiên, nó cung cấp một hệ thống bảo mật rất linh hoạt!&#x20;

* Mặc định, mọi thứ đều được bảo vệ!&#x20;
* Một chuỗi bộ lọc đảm bảo xác thực và ủy quyền đúng đắn.

## How does Spring MVC Work?

<figure><img src="https://www.tutorialspoint.com/spring/images/spring_dispatcherservlet.png" alt=""><figcaption></figcaption></figure>

_`DispatcherServlet`_ hoạt động như bộ điều khiển trung tâm (front controller)&#x20;

* Chặn tất cả các yêu cầu&#x20;
* Routes đến Controller phù hợp

## How does Spring Security Work?

<figure><img src="https://ucarecdn.com/214ecf66-9e12-4579-8a1b-48b4bc86077a/" alt=""><figcaption></figcaption></figure>

Spring Security chặn tất cả các yêu cầu

Tuân theo nguyên tắc bảo mật sau đây

* Có trung gian hoàn chỉnh (Complete Mediation)

Spring Security thực thi một loạt các bộ lọc

* Cũng được gọi là Chuỗi Bộ lọc Spring Security

Spring Security thực thi một loạt các bộ lọc (filters). Các bộ lọc cung cấp các tính năng sau đây:

* Xác thực (Authentication): Liệu người dùng có hợp lệ không? (Ví dụ: BasicAuthenticationFilter)
* Ủy quyền (Authorization): Người dùng có quyền truy cập đúng không? (Ví dụ: AuthorizationFilter)

Các tính năng khác:

* Cross-Origin Resource Sharing (CORS) - CorsFilter:  Có cho phép cuộc gọi AJAX từ các miền khác không?
* Cross Site Request Forgery (CSRF) - CsrfFilter: Một trang web độc hại sử dụng thông tin xác thực trước đó trên trang web của bạn. Mặc định: Bảo vệ CSRF được kích hoạt cho các yêu cầu cập nhật - POST, PUT, v.v.
* Trang Đăng nhập, Trang Đăng xuất: LogoutFilter, DefaultLoginPageGeneratingFilter, DefaultLogoutPageGeneratingFilter.
* Chuyển đổi Exception thành Phản hồi Http chính xác (ExceptionTranslationFilter).

Thứ tự của các bộ lọc là quan trọng (thứ tự điển hình được hiển thị dưới đây)

1. Các bộ lọc kiểm tra cơ bản - CORS, CSRF, ...
2. Các bộ lọc Authen
3. Các bộ lọc Author

## Default Spring Security Configuration

Everything is authenticated

* Bạn có thể tùy chỉnh thêm

Xác thực qua biểu mẫu được kích hoạt (với biểu mẫu mặc định và tính năng đăng xuất)&#x20;

Xác thực cơ bản được kích hoạt Người dùng kiểm tra được tạo&#x20;

Thông tin đăng nhập được in trong log (Tên người dùng là "user")&#x20;

Bảo vệ CSRF được kích hoạt&#x20;

Các yêu cầu CORS bị từ chối X-Frame-Options được đặt là 0 (Frames bị disable)&#x20;

Và nhiều điều khác...

## Khám phá Form Based Authentication

<figure><img src="https://www.appsdeveloperblog.com/wp-content/uploads/2019/12/Screen-Shot-2019-12-02-at-5.14.44-PM-1024x562.jpg" alt=""><figcaption></figcaption></figure>

Được sử dụng bởi hầu hết các ứng dụng web&#x20;

Sử dụng một Cookie Session&#x20;

* JSESSIONID: E2E693A57F6F7E4AC112A1BF4D40890A&#x20;

Spring Security mặc định kích hoạt xác thực dựa trên biểu mẫu&#x20;

Cung cấp Trang Đăng nhập mặc định&#x20;

Cung cấp Trang Đăng xuất mặc định&#x20;

Cung cấp URL _`/logout`_

Bạn có thể thêm trang thay đổi mật khẩu&#x20;

* (http.passwordManagement (Customizer.withDefaults()))

## Khám phá Basic Authentication

Tùy chọn cơ bản nhất để bảo mật REST API

* NHƯNG có nhiều điểm yếu&#x20;
* KHÔNG được khuyến nghị sử dụng trong production.

Tên người dùng và mật khẩu được mã hóa theo Base 64 và gửi dưới dạng **request header**

* Authorization: Basic aW4yOG1pbnV0ZXM6ZHVtbXk=&#x20;
* (ĐIỂM YẾU) Dễ dàng giải mã

Basic Auth Authorization Header:

* KHÔNG chứa authorization information (user access, roles,..)&#x20;
* KHÔNG có Expiry Date

## Bắt đầu với Cross-Site Request Forgery (CSRF)

1. Bạn đã đăng nhập vào trang web ngân hàng của mình (Một cookie Cookie-A được lưu trong trình duyệt web của bạn ).
2. Bạn truy cập vào một trang web độc hại mà không đăng xuất.
3. Trang web độc hại thực hiện một giao dịch chuyển tiền mà không có sự đồng ý của bạn bằng cách sử dụng Cookie-A.

Làm thế nào để bảo vệ khỏi CSRF?

1. Mô hình mã thông báo đồng bộ hóa (Synchronizer token pattern) \
   \- Một mã thông báo được tạo cho mỗi yêu cầu \
   \- Để thực hiện cập nhật (POST, PUT, ..), bạn cần có mã thông báo CSRF từ yêu cầu trước đó
2. SameSite cookie (Set-Cookie: SameSite=Strict) \
   \- trong tệp application.properties (server.servlet.session.cookie.same-site=strict) \
   \- Tùy thuộc vào sự hỗ trợ của trình duyệt.

## Bắt đầu với CORS

```java
@Bean
    public WebMvcConfigurer corsConfigurer() {
        return new WebMvcConfigurer() {
            public void addCorsMappings(CorsRegistry registry) {
                registry.addMapping("/**")
                        .allowedMethods("*")
                        .allowedOrigins("http://localhost:3000");
            }
        };
    }
```

Trình duyệt KHÔNG cho phép cuộc gọi AJAX tới các tài nguyên nằm ngoài nguồn gốc hiện tại

Cross-Origin Resource Sharing (CORS): Đặc tả cho phép bạn cấu hình các cross-domain requests are allowed

* Global Configuration \
  \-  Configure addCorsMappings callback method in WebMvcConfigurer&#x20;
* Local Configuration \
  \-  @CrossOrigin - Allow from all origins \
  \-  @CrossOrigin(origins = "https://www.in28minutes.com") - Allow from specific origin

## Storing User Credentials

```java
@Bean
    public UserDetailsService userDetailsService(DataSource dataSource) {
        UserDetails user = User.builder()
        .username("vick7")
        //.password("{noop}dummy")
        .password("dummy")
        .roles("USER")
        .passwordEncoder(str -> passwordEncoder()
        .encode(str))
        .build();
        JdbcUserDetailsManager users = new JdbcUserDetailsManager(dataSource);
        users.createUser(user);
        return users;
        //return new InMemoryUserDetailsManager(user);
    }
```

* **In Memory** - For test purposes. Not recommended for production.&#x20;
* **Database** - You can use JDBC/JPA to access the credentials.
* **LDAP -**  Lightweight Directory Access Protocol
  * Open protocol for directory services and authentication

## Encoding vs Hashing vs Encryption

<figure><img src="https://3675486674-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fw92IJ3TT5PmyqlZuDfr2%2Fuploads%2FEs418cuTeGsaCvAPRHxb%2Fimage.png?alt=media&#x26;token=a21be444-e847-4a78-a916-2576dd4cdcd3" alt=""><figcaption></figcaption></figure>

#### Mã hóa (Encoding): Chuyển đổi dữ liệu từ một dạng sang dạng khác

* KHÔNG sử dụng khóa hoặc mật khẩu&#x20;
* Có thể đảo ngược&#x20;
* Thường KHÔNG được sử dụng để bảo mật dữ liệu&#x20;
* Các trường hợp sử dụng: Nén, Truyền dữ liệu liên tục (Streaming)&#x20;
* Ví dụ: Base 64, Wav, MP3

#### Băm (Hashing): Chuyển đổi dữ liệu thành một chuỗi băm (hash)

<figure><img src="https://upload.wikimedia.org/wikipedia/commons/5/5e/CPT-Hashing-Password-Login.svg" alt=""><figcaption></figcaption></figure>

* Quá trình một chiều&#x20;
* KHÔNG thể đảo ngược&#x20;
* KHÔNG THỂ lấy lại dữ liệu gốc!&#x20;
* Các trường hợp sử dụng: Xác thực tính toàn vẹn dữ liệu&#x20;
* Ví dụ: bcrypt, scrypt

#### Mã hóa (Encryption): Mã hóa dữ liệu bằng cách sử dụng khóa hoặc mật khẩu

* Bạn cần khóa hoặc mật khẩu để giải mã&#x20;
* Ví dụ: RSA

## Spring Security - Storing Passwords

<figure><img src="https://3675486674-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fw92IJ3TT5PmyqlZuDfr2%2Fuploads%2FUzjh0gvPoxMINM85khsB%2Fimage.png?alt=media&#x26;token=ba54a118-6400-42b5-8b0f-d51056d477c8" alt=""><figcaption></figcaption></figure>

Các thuật toán băm như SHA-256 không còn an toàn nữa

Hệ thống hiện đại có thể thực hiện hàng tỷ phép tính băm mỗi giây VÀ hệ thống càng ngày càng được cải tiến!

Đề xuất: Sử dụng các hàm một chiều có tính năng thích ứng với hệ số công việc là 1 giây

* Việc xác minh mật khẩu trên hệ thống của bạn nên mất ít nhất 1 giây
* Ví dụ: bcrypt, scrypt, argon2, ..

PasswordEncoder - interface để thực hiện quá trình biến đổi một chiều của mật khẩu

* ( REMEMBER) Có tên gây nhầm lẫn!&#x20;
* BCryptPasswordEncoder

## Bắt đầu với JWT

### Basic Authentication

No Expiration Time&#x20;

No User Details&#x20;

Easily Decoded

### How about a custom token system ?

Custom Structure

Possible Security Flaws&#x20;

Service Provider & Service Consumer should understand

### **JWT (Json Web Token)**&#x20;

is an open, industry-standard for representing claims securely between two parties. It can contain user details and authorizations.

## What does a JWT contain?

<figure><img src="https://cdn2.auth0.com/website/learn/assets/jwt-sample.png" alt=""><figcaption></figcaption></figure>

### Header

Type: JWT&#x20;

Hashing Algorithm: HS512

### Payload

#### Standard Attributes:

* iss: The issuer
* sub: The subject
* aud: The audience
* exp: When the token expires
* iat: When the token was issued

#### Custom Attributes:

* yourattribute1: Your custom attribute1

#### Signature

* Includes a Secret

## Symmetric Key Encryption

<figure><img src="https://www.ssl2buy.com/wp-content/uploads/2015/12/Symmetric-Encryption.png" alt=""><figcaption></figcaption></figure>

Các thuật toán mã hóa đối xứng sử dụng cùng một khóa cho quá trình encryption và decryption.

* Key Factor 1: Choose the right encryption algorithm.
* Key Factor 2: How do we secure the encryption key?&#x20;
* Key Factor 3: How do we share the encryption key?

## Asymmetric Key Encryption

<figure><img src="https://www.ssl2buy.com/wp-content/uploads/2015/12/Asymmetric-Encryption.png" alt=""><figcaption></figcaption></figure>

Two Keys: Public Key and Private Key

Also called **Public Key Cyptography**

Encrypt data with Public Key and decrypt with Private Key

Share Public Key with everybody and keep the Private Key with you(YEAH, ITS PRIVATE!)

<details>

<summary>No crazy questions: Will somebody not figure out private key using the public key?</summary>

Không, việc tìm ra khóa bí mật bằng cách sử dụng khóa công khai trong các thuật toán mã hóa không đối xứng như RSA hoặc ECC (Elliptic Curve Cryptography) là không khả thi tính toán. Sự bảo mật của mã hóa không đối xứng dựa trên các tính chất toán học của các thuật toán cụ thể, làm cho việc suy ra khóa bí mật từ khóa công khai tương ứng trở nên vô cùng khó khăn.

Trong mã hóa không đối xứng, khóa công khai được thiết kế để được chia sẻ công khai, trong khi khóa bí mật được giữ bí mật bởi chủ sở hữu. Khóa công khai có thể được sử dụng để mã hóa, tạo chữ ký số và các hoạt động mật mã khác, nhưng nó không thể được sử dụng để suy ra khóa bí mật.

Sức mạnh của mã hóa không đối xứng nằm trong khả năng tính toán phức tạp của việc phân tích các số lớn hoặc giải quyết các vấn đề toán học phức tạp, điều này là cơ sở cho tính bảo mật của các thuật toán này. Miễn là khóa bí mật được giữ an toàn và thuật toán mã hóa được triển khai đúng cách, rất khó có thể suy ra khóa bí mật chỉ từ khóa công khai.

</details>

{% hint style="info" %}
**Best Practice:** Use Asymmetric Keys
{% endhint %}

## Understanding High Level JWT Flow

<figure><img src="https://images.ctfassets.net/kbkgmx9upatd/2qcBkSHR7Rfs0UIZYhjd7k/b428b00508dca46d67f48c81019cdcc8/jwt-diagram.png" alt=""><figcaption></figcaption></figure>

### Create a JWT

Needs Encoding

* User credentials&#x20;
* User data (payload)&#x20;
* RSA key pair

We will create a JWT Resource for creating JWT later

### Send JWT as part of request header

Authorization Header&#x20;

Bearer Token

Authorization: `Bearer ${JWT_TOKEN}`

### JWT is verified

Needs Decoding&#x20;

RSA key pair (Public Key)

## JWT Security Configuration

<figure><img src="https://docs.spring.io/spring-security/reference/_images/servlet/oauth2/jwtauthenticationprovider.png" alt=""><figcaption></figcaption></figure>

### JWT Authentication using Spring Boot’s OAuth2 Resource Server

#### Create Key Pair

Đầu tiên, chúng ta cần tạo một cặp key. Điều này có thể được thực hiện bằng cách sử dụng lớp `java.security.KeyPairGenerator` được cung cấp bởi Java. Theo cách khác, bạn cũng có thể sử dụng OpenSSL để tạo cặp key.

#### Create RSA Key object using Key Pair

Sau khi cặp khóa được tạo, chúng ta cần tạo một đối tượng khóa RSA bằng cách sử dụng cặp key đã tạo. Trong trường hợp này, chúng ta có thể sử dụng lớp `com.nimbusds.jose.jwk.RSAKey` để đại diện cho RSA key.

#### Create JWKSource (JSON Web Key source)

Tiếp theo, chúng ta tạo một JWKSource, là nguồn cung cấp JSON Web Key. Chúng ta bắt đầu bằng cách tạo một JWKSet, đó là một tập hợp các JSON Web Key. Chúng ta thêm RSA key đã tạo trước đó vào JWKSet. Sau đó, chúng ta tạo JWKSource bằng cách sử dụng JWKSet.

#### Use RSA Public Key for Decoding

Để giải mã một JWT, chúng ta cần sử dụng khóa công khai RSA. Chúng ta cấu hình NimbusJwtDecoder để sử dụng khóa công khai RSA được lấy từ đối tượng RSA Key đã tạo trước đó.

* `NimbusJwtDecoder.withPublicKey(rsaKey().toRSAPublicKey()).build()`

#### Use JWKSource for Encoding

Để encoding một JWT, chúng ta sử dụng JWKSource. Chúng ta tạo một phiên bản mới của NimbusJwtEncoder, truyền JWKSource vào đó.

* `return new NimbusJwtEncoder(jwkSource());`

## JWT Resource

```json
username:"vick7dev",
password:"thisispassword"
Response
{
"token": "TOKEN_VALUE"
}
```

#### Step 1: Sử dụng Basic Auth để lấy JWT Token

Trong bước này, chúng ta sử dụng phương thức Basic Auth để xác thực người dùng và lấy JWT Token. Phương thức Basic Auth yêu cầu người dùng cung cấp thông tin đăng nhập (username và password) trong request header. Sau khi thông tin đăng nhập được xác thực thành công, máy chủ sẽ trả về một JWT Token cho người dùng.

#### Step 2-n: Sử dụng JWT token như là Bearer Token để authenticate requests

Sau khi có JWT Token từ bước trước, chúng ta sẽ sử dụng nó như là Bearer Token để xác thực các request gửi đến server. Điều này được thực hiện bằng cách thêm JWT Token vào  request header với phương thức "Bearer" trong phần "Authorization". Server sẽ verify và validate tính hợp lệ của JWT Token trước khi xử lý request.

Các bước trên giúp thực hiện JWT authentication bằng cách sử dụng phương thức Basic Auth để lấy JWT Token và sau đó sử dụng JWT Token như là Bearer Token để authenticate các requests gửi đến server.

## Understanding Spring Security Authentication

<figure><img src="https://backendstory.com/content/images/2022/02/7.-Scenario-5.1---Multiple-Custom-AuthenticationProvider-1.png" alt=""><figcaption></figcaption></figure>

Xác thực được thực hiện là một phần của **Spring Security Filter Chain!**

1. **AuthenticationManager** - Được sử dụng để thực hiện quá trình xác thực. Nó có khả năng tương tác với nhiều nhà cung cấp xác thực khác nhau để thực hiện xác thực theo các phương thức khác nhau (ví dụ: xác thực bằng tên người dùng và mật khẩu, xác thực JWT, v.v.).
2. **AuthenticationProvider** - Là một thành phần con của AuthenticationManager và thực hiện quá trình xác thực cụ thể dựa trên loại xác thực được yêu cầu. Ví dụ, JwtAuthenticationProvider là một AuthenticationProvider được sử dụng để xác thực JWT.
3. **UserDetailsService** - Là một core interface trong Spring Security, được sử dụng để tải dữ liệu người dùng từ nguồn dữ liệu như cơ sở dữ liệu. Nó cung cấp thông tin về người dùng, bao gồm tên người dùng, mật khẩu và các quyền (roles) của người dùng.

Kết quả xác thực được lưu trữ trong các đối tượng sau:

1. **SecurityContextHolder**: Lưu trữ thông tin bảo mật trong một ngữ cảnh bảo mật.
2. **SecurityContext**: Đại diện cho ngữ cảnh bảo mật hiện tại và chứa thông tin về quá trình xác thực.
3. **Authentication**: Đại diện cho kết quả của quá trình xác thực sau khi thành công. Nó chứa thông tin về người dùng đã xác thực (Principal) và các quyền (GrantedAuthority) của người dùng.
4. **GrantedAuthority:** đại diện cho các quyền được cấp cho người dùng, ví dụ như vai trò (roles), phạm vi (scopes), và các quyền khác liên quan đến quyền truy cập vào các tài nguyên và chức năng trong hệ thống.

Tóm lại, trong quá trình xác thực trong Spring Security, AuthenticationManager được sử dụng để thực hiện xác thực, các AuthenticationProvider cung cấp xác thực cụ thể, và UserDetailsService tải thông tin người dùng. Kết quả xác thực được lưu trữ trong SecurityContextHolder, SecurityContext, Authentication, và GrantedAuthority để đảm bảo quyền truy cập và xác thực đúng cho người dùng trong hệ thống.

## Triển khai Spring Security Authorization

<figure><img src="https://docs.spring.io/spring-security/reference/_images/servlet/authentication/architecture/securitycontextholder.png" alt=""><figcaption></figcaption></figure>

### Global Security: authorizeHttpRequests

```java
.requestMatchers("/users").hasRole("USER")
```

* hasRole, hasAuthority, hasAnyAuthority, isAuthenticated

Trong Global Security, chúng ta sử dụng đoạn code authorizeHttpRequests để xác định quyền truy cập cho các HTTP request. Ví dụ trên xác định rằng chỉ những người dùng có vai trò "USER" mới có quyền truy cập vào đường dẫn "/users". Trong Spring Security, chúng ta có thể sử dụng các phương thức như hasRole, hasAuthority, hasAnyAuthority, isAuthenticated để xác định quyền truy cập dựa trên vai trò, quyền hoặc trạng thái xác thực của người dùng.

### Method Security (@EnableMethodSecurity)

#### @Pre and @Post Annotations

* `@PreAuthorize("hasRole('USER') and #username == authentication.name")`&#x20;
* `@PostAuthorize("returnObject.username == 'vick7dev'")`

Trong bảo mật phương thức, chúng ta sử dụng các chú thích @Pre và @Post để xác định quyền truy cập cho các phương thức cụ thể trong ứng dụng. Ví dụ trên sử dụng @PreAuthorize để xác định rằng chỉ những người dùng có vai trò "USER" và #username trùng khớp với authentication.name mới có quyền truy cập vào phương thức. @PostAuthorize được sử dụng để kiểm tra kết quả trả về của phương thức, trong trường hợp này, nếu trường "username" của đối tượng trả về là '`vick7dev`' thì quyền truy cập được cho phép.

#### JSR-250 annotations&#x20;

* `@EnableMethodSecurity(jsr250Enabled = true)`
* `@RolesAllowed({"ADMIN" , "USER"})`

Các chú thích JSR-250 như `@RolesAllowed` cũng được sử dụng để xác định các vai trò có quyền truy cập vào phương thức. `@Secured` là một chú thích khác để xác định các vai trò có quyền truy cập, và nó được kích hoạt bằng `@EnableMethodSecurity(securedEnabled = true)`.

#### @Secured annotation

* `@EnableMethodSecurity(securedEnabled = true)`&#x20;
* `@Secured({"ADMIN" , "USER"})`

{% hint style="info" %}
JWT: Use `hasAuthority('SCOPE_ROLE_USER')`
{% endhint %}

&#x20;Trong trường hợp sử dụng JWT, chúng ta có thể sử dụng `hasAuthority('SCOPE_ROLE_USER')` để xác định quyền truy cập dựa trên phạm vi của vai trò trong JWT.

## OAuth

Làm thế nào để cung cấp quyền truy cập cho ứng dụng vào các tệp tin trên Google Drive của bạn?

* Mà không cần cung cấp thông tin đăng nhập của bạn (KHÔNG AN TOÀN)

OAuth: Industry-standard protocol for authorization

* Đồng thời hỗ trợ cả authentication.

Hãy giả sử bạn muốn cung cấp quyền truy cập vào các tệp tin Google Drive của bạn cho ứng dụng quản lý Todo!

Important Concepts:

* Resource owner: You (Person owning the google drive files)&#x20;
* Client application: Todo management application&#x20;
* Resource server: Contains the resources that are being accessed - Google Drive&#x20;
* Authorization server: Google OAuth Server





