스프링 시큐리티 OAuth2의 기본 개념부터 API 사용법과 내부 아키텍처를 학습합니다. 아울러 OAuth2 Client, OAuth2 Resource Server, Authorization Server를 통합하여 연동하는 방법을 살펴보고 자체 인가 서버를 구축하며 이를 통해 OAuth2 서비스를 구현하는 방법을 학습하게 됩니다.
막강한 인증/인가 처리를 위한 최선의 선택! 제대로 배우는 스프링 시큐리티 OAuth2 🔐
스프링 시큐리티 OAuth2?
Spring Security OAuth2는 OAuth 2.0 Authorization Framework 표준 기술 사양을 채택하여 OAuth2 Client, Resource Server, Authorization Server 군으로 분류하여 API를 제공하고 있습니다.
전통적인 세션 기반 인증 방식의 강력한 대안
과거부터 현재에 이르기까지 레거시 시스템의 전통적인 인증 및 인가 방식으로 세션/쿠키를 활용한 기술을 많이 사용하고 있습니다. 그러나 시스템의 규모가 커지고 모바일, 태블릿, PC, IOT 등 다양한 기기의 인증 처리를 하는 데 있어 세션 공유 문제나 서버 자원 부담, 보안 안전성, 복잡한 아키텍처 구성 등 기존 세션 방식의 인증 구성이 여러 문제와 한계를 지닌 것으로 인식되고 있습니다.
특히 모놀리틱이 아닌 MSA 방식의 인프라가 점점 추세가 되고 있는 현시점에서는 더더욱 세션 기반 인증방식이 효율적인 대안이 되지 못하는 것도 사실입니다.
이에 위 한계점과 문제들을 해결하기 위한 방식으로 세션이 아닌 토큰 방식으로 인증/인가처리를 하기 위한 필요성이 대두되어 OAuth, JWT와 같은 인증 처리 기술들이 탄생했습니다. 이리하여 글로벌 기업인 구글, 페이스북, 깃헙에서 서비스하는 OAuth 서비스를 활용해 더욱 간결하고 강력한 인증/인가 처리를 할 수 있게 되었습니다.
본 강의는 스프링 시큐리티 OAuth2 지식을 처음 접하는 입문자부터 기초적인 지식이나 사용 경험은 있지만 좀 더 깊이 있는 지식 습득과 스프링 시큐리티 OAuth2의 핵심 원리, 내부 구조, 동작 방식 등을 심도 있게 이해하고 이를 응용하고자 하는 중~고급자 분들을 위해 제작되었습니다.
스프링 시큐리티 OAuth 핵심 이해 강의는
🔑
단순한 API 사용법과 문법만을 학습하지 않습니다. 인가 기술의 원리와 구조를 토대로 핵심 기술에 대한 이해를 높입니다.
🎓
스프링 시큐리티 OAuth2가 어떤 구조로 동작하는지 정확한 흐름들을 이해하고 원리를 파악하도록 합니다.
🧰
스프링 시큐리티 OAuth2가 제공하는 기본 기능을 확장하여 커스터마이징하는 역량을 기를 수 있습니다.
✅
스프링 시큐리티 OAuth2의 기술을 어떻게 실무적으로 활용할 수 있을지에 대한 감각을 익히게 됩니다.
주요 학습 내용
💡 본 강의는 OAuth 2.0 표준 기술과 이를 바탕으로 한 스프링 시큐리티 OAuth2의 핵심 개념인 OAuth2 Client, Resource Server, Authorization Server의 세 가지 축을 중심으로 수업을 진행합니다.
1) OAuth 2.0 Authorization Framework
RFC 표준 기술인 OAuth 2.0 인가 프레임워크의 전반적인 개념과 원리, 구조 등의 내용을 살펴봅니다.
스프링 시큐리티 OAuth2의 본격적인 기술을 학습하기에 앞서 OAuth 2.0 의 표준 기술에 대한 기초와 기본적인 이론을 먼저 이해하고, 실습을 통해 정확한 개념을 숙지함으로서 스프링 시큐리티 OAuth2의 내용을 어려움 없이 따라갈 수 있도록 합니다.
2) OAuth2 Client
OAuth 2.0 의 클라이언트 모듈로서 클라이언트에서 인가 서버와 연동할 수 있는 여러 유형의 권한 부여 타입과 요청 API를 소개하며 인가서버로부터 발급받은 토큰을 사용하여 리소스 서버로의 접근제어를 어떻게 구현하는가에 대한 내용을 학습합니다.
또한 구글, 페이스북, 깃헙, 네이버 , 카카오 등 OAuth 2.0 Authorization Server 서비스 제공자와의 연동을 통해 소셜 로그인 기능을 구현하는 방법을 소개합니다. 그리고 인증 프로토콜인 OpenID Connect 를 소개하며 인증 처리를 위한 다양한 옵션 설정방법과 흐름을 이해합니다.
3) OAuth2 Resource Server
사용자의 자원을 보호하고 있는 서버로서 API 서버의 역할을 수행하게 됩니다. 리소스 서버가 자원을 보호하는 방법을 살펴보고 Access Token을 포함한 요청에 대해서 토큰의 유효성을 검증하는 방법과 권한 체계를 제어하는 흐름에 대해 학습합니다.
OAuth2 서비스 제공자에서 발급하는 Access Token이 JWT 포맷으로 생성된 토큰일 경우 Scope(범위) 를 추출하는 내용을 살펴보고 리소스 서버에서 Access Token에 포함된 Scope를 분석하여 권한 여부를 어떻게 판별하는지 내용을 학습합니다.
4) OAuth2 Authorization Server
시중에는 오픈소스를 포함한 다양한 Authorization Server 상용 제품 및 서비스가 있습니다. 스프링 시큐리티 개발팀에서 Authorization Server 프레임워크 프로젝트를 중단하기도 했지만 수많은 개발자들의 빗발치는 요청으로 Authorization Server 프로젝트가 완전히 새로운 설계로 다시금 탄생했습니다.
본 강의에서는 새로운 아키텍처로 재탄생한 Authorization Server 프로젝트를 기준으로 강의를 제작했습니다. OAuth2 Client와 Resource Server와의 연동을 통한 인가서버로서의 기능에 대한 상세한 내용을 살펴보며 자체적으로 인가 서버를 구축하여 서비스할 수 있는 지식을 갖추도록 하는 데 중점을 두었습니다.
Authorization Server 기능을 처리하는 주요 클래스를 알아보고 커스터마이징할 수 있는 방법을 알아봅니다. 또한 OAuth 2.0 표준 엔드 포인트에 대한 사양을 살펴보고 각 엔드포인트마다 설정된 필터들의 구조와 처리 과정을 학습합니다.
아키텍처/흐름/원리를 두루 이해할 수 있습니다.
스프링 프레임워크 프로젝트 가운데 스프링 시큐리티는 기술 아키텍처, 동작원리, 흐름 이해 등의 내부 소스 레벨의 구현에 대한 전반적인 이해가 굉장히 중요합니다.
주어진 API 위주로 사용하다가 예기치 못한 오류나 이슈에 부딪치게 되면 구글에 검색해서 해결방안을 찾기 마련입니다. 그러나 스프링 시큐리티 OAuth2 에 관한 자료들이 많지 않고 대부분 비슷한 사례들이 반복해서 나오는 수준이기 때문에 스프링 시큐리티 OAuth2의 내부 구조와 동작 원리를 정확하게 이해하지 못하거나 분석이 되지 못한다면 서비스 운영에 많은 어려움을 겪게 됩니다.
그렇기 때문에 이번 강의는 다양한 도식 및 Flow와 디버깅을 통한 정확하고 상세한 설명을 통해 단순한 API 사용법과 기능 예제를 넘어 스프링 시큐리티 OAuth2의 구조와 흐름을 완전하게 분석하고 이해함으로서 어떤 상황에서도 유연한 대처가 가능한 지식을 갖추도록 하는 데 중점을 두고 있습니다. 이는 본 강사가 개설한 강의들의 패턴 및 공통적인 특징이라 할 수 있습니다.
강의 구성 및 상세 커리큘럼
Part 1. 스프링 부트 기반으로 개발하는 스프링 시큐리티
스프링 시큐리티의 핵심 개념인 인증과 인가의 두 축을 중심으로 강의가 진행됩니다. 스프링 시큐리티의 기초와 기본이 굉장히 중요하기 때문에 Part. 1에서는 스프링 시큐리티를 구성하는 핵심 구조 및 인증, 그리고 인증과 관련된 주요 항목들에 대한 정확한 개념을 이해하고 예제와 실습을 통해 실무적인 개발에 도움이 되도록 구성했습니다.
Part. 1을 수강하게 되면 스프링 시큐리티의 전체적인 Fundamentals을 확실하게 정립함과 동시에 더 나아가 보안 시스템 구축 시 시큐리티 기본구조를 확장하고 응용이 가능한 수준의 역량을 기르게 됩니다.
Part 2. 스프링 부트 기반으로 개발하는 스프링 시큐리티 OAuth2
OAuth2의 기본 개념과 흐름의 정확한 이해와 스프링 시큐리티 OAuth2의 핵심 모듈인 OAuth2 Client, Resource Server, Authorization Server의 기술에 대해 학습합니다. Part. 2를 원활하게 학습하기 위해서는 Part. 1의 기본 내용에 대한 이해가 필수이기 때문에 반드시 사전에 지식을 습득한 후 수강해야 합니다.
Part. 2에서는 OAuth2에 관한 다양한 기술들이 복합적으로 구성되어 있기 때문에 방대한 OAuth2 관련 개념을 충분히 이해하고 이를 바탕으로 클라이언트 앱, 리소스 서버, 인가서버 상호간의 연동 과정을 상세하고 깊이 있게 분석하고 살펴봅니다.
Spring Security Fundamentals
스프링 시큐리티의 핵심 기초를 살펴봅니다. 초기화 과정에 대한 자세한 내용과 원리를 알아보고 HttpBasic, Cors와 같은 요소를 다룹니다.
OAuth 2.0 Authorization Framework
OAuth 2.0 표준 기술에 대한 상세 사양에 대해 학습합니다. OAuth 2.0에서 표현되는 다양한 용어를 먼저 이해하고 권한부여 흐름의 타입에 대한 개념 정리와 keycloak 오픈 소스를 활용해 인가 프레임워크의 전반적인 흐름을 이해합니다.
OAuth 2.0 Client - oauth2Login()
클라이언트 앱의 기능을 자동화하며 권한부여 흐름의 타입인 Authorization Code 방식으로 인가서버와의 연동방법을 학습하며 사용자 승인과 승인 이후 Access Token 을 받아와 인증/인가 처리에 이르기까지의 전 과정을 살펴보고 내부구조에 대해 학습하게 됩니다.
OAuth 2.0 Client - oauth2Client()
oauth2Login() API에서 제공하는 권한부여 흐름의 타입인 Authorization Code 외에 Resource Owner Password와 Client Credentials 타입으로 인가서버와 연동하는 방법을 살펴보며 DefaultOAuth2AuthorizedClientManager, @RegisteredOAuth2AuthorizedClient의 사용방법을 알아보고 이를 통해 클라이언트 권한부여 흐름을 이해합니다.
OAuth 2.0 Client - OAuth 2.0 Social Login
OAuth2 서비스 제공자로 구글, 페이스북, 깃헙, 네이버, 카카오 등이 있는데 이중 구글, 네이버, 키클록을 사용하여 로그인 인증하는 방식과 인증 이후 후속처리에 대한 구현방법을 살펴봅니다.
OAuth 2.0 Resource Server API - jwt()
리소스 서버를 구성하는 방법과 Access Token 요청을 처리하는 JwtDecoder의 기능을 살펴보고 토큰 검증의 성공이후 생성되는 인증관련 객체의 구조와 사용방법을 학습합니다. 또한 Access Token의 유효성을 검증할 때 사용되는 MAC & RSA 알고리즘 방식이 무엇이며 어떤 처리절차에 의해 검증이 이루어지는지 살펴봅니다.
OAuth 2.0 Resource Server - 리소스 서버 권한 구현
Access Token 요청을 처리하는 필터와 JwtDecoder에 의해 추출된 Scope를 권한으로 변환하고 변환된 권한으로 자원의 접근여부를 제어하는 방법에 대해 학습합니다.
OAuth 2.0 Resource Server - opaque()
원격 토큰 검사 프로세스로서 Access Token의 활성화 여부를 인가서버와 직접 통신하여 알아보는 방법을 학습합니다.
Spring Authorization Server - 주요 도메인 클래스
인가서버를 구성하는 주요 도메인 클래스의 종류와 개념, 역할 등을 학습하며 이 클래스들이 스프링 MVC에서 어떤 방식으로 참조 및 활용이 가능한지 학습합니다.
Spring Authorization Server - 엔드포인트 프로토콜
인가서버의 핵심 기능인 여러 유형의 엔드포인트 프로토콜에 대해 학습합니다. 권한 부여 요청을 시작한 엔드포인트 부터 사용자 정보를 요청하는 엔드포인트까지의 전 과정을 도식과 흐름을 통해 자세하게 살펴보게 됩니다.
OAuth 2.0 Client + Resource Server + Authorization Server 연동
스프링 시큐리티에서 제공하는 각 OAuth2의 모듈들을 연계 및 연동하는 방법을 알아보고 이를 통해 OAuth2 서비스 제공자로서의 기능을 수행하는 구체적인 항목들을 예제를 통해 살펴보게 됩니다.
다양한 프로젝트에서 웹/모바일/솔루션 제품 개발과 관련된 업무를 진행해 오고 있으며 분석/설계/개발 Role 을 맡아 오고 있습니다.
공공기간, 교육프로그램, 기업 프로젝트, 쇼핑몰 등의 웹 개발 및 솔루션 프로그램, 프레임워크, 오픈소스 연동 등의 아키텍처 설계 및 구조적 고도화 개선 등을 해 오고 있으며 개발, PL 등의 역할을 맡았습니다.
다양한 Open Source 와 여러 기술적인 경험들을 통해 웹의 전반적인 기술 흐름들을 익혔으며 개발 경험이 거듭될 수록 요구사항의 기능 구현에만 거치지 않고 좀 더 OOP 적인 구조의 소프트웨어로서 안전성과 성능을 고려한 아키텍처링과 튜닝의 기술들을 접목시켜 지속적으로 더 훌륭한 소프트웨어를 완성하기 위한 연구와 개발 실무를 책임감 있게 맡아 오고 있습니다.
Xin chào. Tôi rất thích các bài giảng về bảo mật và OAUTH2.
Tôi có thể cảm nhận được rằng người hướng dẫn đã chuẩn bị rất nhiều cho bài giảng và cũng rất tâm huyết.
Ngoài ra, anh ấy còn là một người rất hiểu biết.
Tuy nhiên, tôi nghĩ sẽ tốt hơn nếu cải tiến phương pháp giảng dạy một chút.
1. Tôi cảm thấy lời giải thích hơi vội vàng. Đây là một savasa, nhưng tôi nghĩ việc dẫn dắt bài giảng một cách bình tĩnh là một cách để giảm bớt nó. Đôi khi, tôi không biết một từ là gì vì cách phát âm.
2. Cấu trúc bài giảng khiến học sinh khó có thể tự học. Về cơ bản, tôi không còn lựa chọn nào khác ngoài việc làm theo. Trong tình huống như vậy, nếu giảng viên và sinh viên không đồng bộ đúng cách và bối cảnh của giảng viên khác với bối cảnh của sinh viên thì sinh viên sẽ rất căng thẳng. Trong cộng đồng, đôi khi tôi thấy những bài viết có phần xúc động bày tỏ sự không hài lòng về lĩnh vực đó. Tôi có thể phần nào hiểu được cảm giác của bạn. Điều này là do hầu hết người mua khóa học đều bắt đầu tham gia các khóa học với kỳ vọng khá cao.
Điều quá rõ ràng theo quan điểm của giảng viên (bạn càng có thâm niên cao và càng có nhiều kiến thức thì xu hướng này càng trở nên mạnh mẽ hơn), thường lại không đúng theo quan điểm của sinh viên.
3. Ví dụ: thật tuyệt khi thực hành các yêu cầu ủy quyền bằng Postman và sau đó chuyển sang Spring. ừm. Vì tốc độ nói nhanh và không có điểm gì đặc biệt nên có cảm giác như những câu chuyện quan trọng đang diễn ra trôi chảy. Ví dụ: khi yêu cầu ủy quyền ban đầu, khi bạn nhấn nút đăng nhập, máy khách sẽ yêu cầu /oauth2/ủy quyền và khi máy khách yêu cầu mã tạm thời từ máy chủ ủy quyền, nó sẽ được gửi đến /oauth2/ủy quyền. xảy ra mọi lúc, nó không được nhận ra trong một thời gian. Tôi hơi bối rối và bối rối trong một thời gian. Vì vậy, tôi đã quen với việc tự mình gỡ lỗi từng bước một. Tôi nghĩ rằng người hướng dẫn có thể không biết những điều như vậy vì họ đã quá quen với nó, nhưng khi giảng bài, họ nói: "URL này có thể hơi khó hiểu." Thông tin đăng nhập đầu tiên là /oauth2/authorization và yêu cầu mã là /oauth2/authorize Trên thực tế, phương thức xử lý ủy quyền bắt đầu khi khách hàng yêu cầu mã, vì vậy ủy quyền có nghĩa là cấp quyền, vì vậy /oauth2/authorize là URL để yêu cầu mã. . Tôi nghĩ sẽ tốt nếu nhớ nó trong bối cảnh này" Việc chỉ ra điều gì đó theo cách tương tự là một điểm rất hữu ích trong học tập đối với học sinh.
4. Có nhiều trường hợp sử dụng mã mới (từ đầu) khi dạy chương tiếp theo. Tôi nghĩ đó cũng chính là lý do khiến ai đó yêu cầu duy trì mã trong bài đánh giá khóa học. Nó chắc chắn rất tiện lợi vì Younghan đã để lại toàn bộ mã sau bài giảng đầu tiên. Quá trình này được thực hiện mà không cần chỉnh sửa, vì vậy bạn có thể học chỉ bằng cách xem và theo dõi, đồng thời nó có lợi thế là đưa học sinh và người hướng dẫn vào cùng một trang.
Bạn có thể bắt đầu từ một chi nhánh mới mỗi lần như người hướng dẫn Suwon, nhưng tôi nghĩ sẽ tốt hơn nếu chỉ có một người hướng dẫn khi bắt đầu khóa học. Mỗi clip hoặc phần được quản lý theo từng nhánh nên chúng tôi khuyến khích học viên làm điều tương tự nếu có thể. Có thể có một số người mới bắt đầu sử dụng Git. Tất cả bạn phải làm là hiển thị nó một lần. Vì tôi sẽ không thổi phồng PR và hợp nhất nó thành chủ, chỉ cần chỉ cho tôi cách tạo một nhánh mới và các sinh viên sẽ ở cùng trang với người hướng dẫn.
5. Cuối cùng, nhấp vào Lọc -> Người quản lý -> Nhà cung cấp -> .. Tôi nghĩ sẽ tốt hơn nếu cho bạn biết về mối quan hệ này trước khi bài giảng thực sự bắt đầu. Nó đã được đề cập từ giữa đến cuối bài giảng. Khi nghe giảng, tôi nhận ra rằng khuôn mẫu đã được thiết lập sẵn, nhưng tôi nghĩ sẽ dễ dàng hơn nếu tôi biết khuôn mẫu đó ngay từ đầu. Có lẽ các bài giảng khác sẽ ít hơn một chút, nhưng vì Bảo mật có quá nhiều lớp và quá chuyên sâu nên hơi bận rộn và tôi bị lạc khi theo dõi các bài giảng. Tất nhiên, ngay từ đầu, người hướng dẫn sẽ chỉ ra quy trình bằng sơ đồ lớp, nhưng khi màn hình chứa đầy các lớp với những cái tên dài mà bạn mới nhìn thấy lần đầu tiên, quy trình sẽ không rõ ràng ngay lập tức. Tất nhiên là điều đó có ích, nhưng tôi vẫn không cảm thấy mình cùng quan điểm với các học sinh.
6. Ồ, và bạn đã nói rõ rằng bạn sẽ lưu nó trong DB trong lần thực hành cuối cùng thay vì lưu vào bộ nhớ, nhưng chắc chắn bạn đã quên giữa chừng nên hơi thất vọng khi buổi thực hành kết thúc bằng trong bộ nhớ cho đến khi kết thúc. Đây là một việc nhỏ, nhưng sẽ tốt hơn nếu bạn đặt tên cho máy chủ tài nguyên giống như ResourceServerPhoto trong bài tập cuối cùng thay vì 1 hoặc 2. Trước đây, khi tôi đang giảng bài về C++, giảng viên nói: "Có thể hơi nhàm chán hoặc không thú vị vì lần nào cũng giống nhau (ví dụ hầu hết được tạo bằng cách chỉ nhập tên, tuổi và một số thông tin khác). thông tin trong lớp Người), nhưng bạn có rất nhiều điều để học trong tương lai." Vì vậy, tôi vẫn nhớ những gì bạn đã nói, "Trong những lĩnh vực này, việc học sẽ dễ dàng hơn khi rào cản đối với cái mới ở mức thấp."
Einstein cho rằng khi giải thích một điều gì đó, ngay cả một bà già không có kiến thức liên quan cũng phải hiểu được, nên tôi đã để lại rất nhiều suy nghĩ về phương pháp giảng dạy.
Tuy nhiên, các sinh viên ơi, bài giảng này, cũng như bảo mật, là một hướng dẫn tuyệt vời để hiểu sâu hơn về khuôn khổ bảo mật. Bây giờ tôi gần như đã biết vị trí và cách đặt điểm dừng khi gỡ lỗi. Nếu điểm ngắt không ở đúng nơi tôi nghĩ, tôi đã tìm kiếm thêm và có thể tìm ra luồng chính xác. Bảo mật và OAUTH2 chắc chắn không phải là những lớp học dễ dàng, nhưng tôi nghĩ bạn có thể học được rất nhiều điều từ chúng nếu bạn nỗ lực.
Tôi đang học tốt. Cảm ơn
Tôi thực sự cảm động vì bạn đã đánh giá khóa học một cách cẩn thận như vậy.
Và cảm ơn bạn rất nhiều vì lời khuyên chân thành của bạn.
Chúng tôi sẽ tính đến những mục bạn đề cập nhiều nhất có thể khi tạo bài giảng.
Tuy nhiên, tôi sẽ đánh giá cao nếu bạn có thể rộng lượng hiểu rằng mặc dù tôi nói rằng tôi chú ý vì thói quen rất đáng sợ nhưng tôi có thể có những thiếu sót ở nhiều mặt.
Bất kể kinh nghiệm hay thâm niên, tôi luôn cố gắng nhìn nhận bản thân với thái độ khiêm tốn, nghĩ rằng trên thế giới có rất nhiều nhà phát triển giỏi hơn tôi nghĩ.
Mặc dù tôi làm giảng viên tại Inferun, nhưng tôi không tin rằng những người hướng dẫn có thể giảng dạy vì họ giỏi hơn hoặc có năng lực hơn học sinh của họ.
Tất nhiên, với tư cách là một giảng viên, bạn nên cố gắng mang lại chất lượng tối đa cho học viên của mình, nhưng điều này không hẳn là do kỹ năng hay khả năng của bạn vượt trội hơn mà vì có những môn học đòi hỏi kiến thức mà người hướng dẫn phải biết. , và trong số các sinh viên, tôi luôn chuẩn bị bài giảng với suy nghĩ rằng sẽ có những nhà phát triển giỏi hơn người hướng dẫn.
Vì chưa đáp ứng được nhiều yêu cầu của một người hướng dẫn chuyên nghiệp, còn khá nhiều sơ hở, chỗ cần cải thiện nên tôi luôn trăn trở khi soạn bài và nỗ lực hoàn thiện.
Một lần nữa, tôi xin cảm ơn sự tư vấn và hỗ trợ chân thành của các bạn. Thay vì ưu tiên lợi ích cá nhân, tôi sẽ luôn nỗ lực trở thành một người hướng dẫn ưu tiên cung cấp những bài giảng không bao giờ làm học sinh thất vọng khi lựa chọn bài giảng của tôi.
Cảm ơn
Đó chắc chắn là một bài giảng thực sự tốt.
Lô mùa xuân > Bảo mật > Tôi đang lắng nghe mọi thứ, kể cả OAuth2.
Vì những người khác đã đề cập đến những ưu điểm nên tôi muốn nói với bạn về một số gợi ý(?) hoặc những điều hối tiếc.
Tôi nghĩ sẽ rất hữu ích khi kiểm tra tất cả các cấp độ mã nguồn của Spring ở chế độ gỡ lỗi. Tất nhiên, người hướng dẫn sẽ kiểm tra trước các điểm nghỉ, nhưng có vẻ không dễ dàng theo dõi màn hình khi nó lướt qua.
Tất nhiên, chẳng có gì đáng nói nếu bạn nói “Tôi cần biết mọi thứ để sử dụng một công nghệ nào đó!!”, nhưng tôi nghĩ bài giảng sẽ gọn gàng và tiết kiệm chi phí hơn nếu bài giảng kết thúc bằng việc giảng viên giải thích lý thuyết. một phần và trích dẫn một số mã nguồn. Đây chắc chắn là một khóa học tốt, nhưng bạn cần đầu tư một lượng lớn thời gian để tìm hiểu tất cả các quy trình sửa lỗi và nếu bạn tham gia khóa học này để sử dụng nó trong thực tế ngay lập tức, bạn có thể nghĩ rằng việc áp dụng nó vào thực tế nên hoãn lại cho đến sau này. .
Tôi đang để lại bài đánh giá khóa học với hy vọng người hướng dẫn sẽ tiếp tục tạo ra những khóa học tốt hơn.
Vâng, cảm ơn đánh giá chân thành của bạn ^^
Như bạn đã nói, việc trình bày quy trình xử lý ở cấp nguồn bằng cách sử dụng tính năng gỡ lỗi trong bài giảng có thể không cần thiết theo một nghĩa nào đó.
Thời gian giảng tương đối dài, có một số điều không thể dễ dàng hiểu được nếu chỉ xem quá trình gỡ lỗi một lần.
Tuy nhiên, lý do đưa các yếu tố gỡ lỗi vào bài giảng là để cung cấp sự hiểu biết rõ ràng về quy trình xử lý nội bộ của khung hoặc thư viện.
Tất nhiên, bạn không cần biết và không thể biết các quy trình và luồng nội bộ của tất cả các mô-đun và API.
Theo quan điểm của tôi, nếu biết quy trình xử lý nội bộ của API này là quan trọng khi triển khai một chức năng nhất định, tôi sẽ giải thích quy trình xử lý tổng thể thông qua việc gỡ lỗi.
Việc gỡ lỗi sẽ không có ý nghĩa gì nếu nó kết thúc bằng việc tự gỡ lỗi.
Bằng cách hiểu rõ ràng mục đích và nguyên tắc thiết kế API thông qua việc gỡ lỗi, tôi hướng tới mục tiêu không chỉ đơn giản là sử dụng API mà còn phát triển khả năng tùy chỉnh mở rộng hoặc áp dụng nó theo ý muốn.
Mặc dù chúng tôi không trực tiếp thiết kế hoặc tạo Spring Security, nhưng đây là một cách tốt để tham gia gián tiếp vào thiết kế công nghệ cốt lõi thông qua việc gỡ lỗi và trải nghiệm một phần cách nó được triển khai.
Khi quá trình này được lặp lại và tích lũy, các ứng dụng tùy chỉnh phức tạp có thể thực hiện được không chỉ dựa trên cách sử dụng API cơ bản mà còn dựa trên sự hiểu biết sâu sắc về công nghệ và có thể phản hồi nhanh chóng khi xảy ra trường hợp ngoại lệ hoặc sự cố.
Tuy nhiên, nếu nhìn vào cấp độ nguồn quá nhiều, bạn có thể bỏ lỡ bức tranh tổng thể nên phải điều chỉnh phân tích theo trình độ và khả năng hiểu biết của mình.
Tôi sẽ tiếp tục suy nghĩ và phát triển để có thể kết hợp việc sử dụng tính năng sửa lỗi ở mức độ thích hợp vào bài giảng của mình bằng cách điều chỉnh nhịp độ và nhịp độ.
Cảm ơn bạn một lần nữa vì đánh giá có giá trị của bạn ^^
Nó giải thích thực sự chi tiết.
Nó đáng nhớ hơn nhiều vì nó cho thấy quá trình gỡ lỗi.
Tôi nghĩ tôi phải nói điều này để nói rằng tôi đã sử dụng OAuth 2.0.
Nếu bạn tiếp tục làm đi làm lại, sẽ đến lúc ngay cả những điều khó khăn nhất cũng trở nên dễ dàng hơn.
Chúc bạn vượt qua những thử thách đó thật tốt.
Cảm ơn đánh giá quý báu của bạn. ^^
Cảm ơn bạn vì bài giảng tuyệt vời :)
Không có bài giảng tiếng Hàn thích hợp nào liên quan đến bảo mật, vì vậy tôi đã cố gắng đưa chúng lên Udemy, nhưng có vẻ như bài giảng hoàn hảo đã xuất hiện vào thời điểm hoàn hảo!! Tôi mới chỉ nghe được khoảng 1/5 nhưng đây thực sự là một bài giảng giàu thông tin!! Rất hài lòng :)
Khóa học tôi chờ đợi đã được ra mắt nên tôi vui vẻ đăng ký.
Tôi đang học tập chăm chỉ.
Tôi thấy rất hữu ích khi tham gia lớp học để hiểu tiêu chuẩn OAuth2 và suy nghĩ về cách Spring Security triển khai mã.
Thực ra thì hơi khó khăn một chút nhưng tôi mong mình có thể kiên trì đến cùng và trưởng thành về mặt cá nhân.
Cảm ơn bạn rất nhiều vì bài giảng tuyệt vời. Giữ sức khỏe nhé ^^
Vâng, cảm ơn bạn ^^
Như bạn đã đề cập, khi tìm hiểu công nghệ Spring Security OAuth2, được triển khai tuân thủ các thông số kỹ thuật tiêu chuẩn OAuth2.0, bạn sẽ sớm tìm hiểu khái niệm OAuth2.0 theo cách bán chuyên nghiệp.
Điều này là do mức độ hoàn thiện kỹ thuật của OAuth2.0 của Spring Security cao.
Khó khăn kỹ thuật tổng thể có thể không dễ dàng, nhưng tôi hy vọng bạn hoàn thành khóa học đến cùng và có kết quả tốt~~