Hãy đào sâu hơn một chút, và cụ thể là chuyển sự chú ý của chúng ta đến OAuth và OpenID Connect (OIDC) như là các giao thức.
Bạn đã từng đọc bất kỳ đặc tả nào của những giao thức này chưa?
Trong quá khứ, các identity protocols có xu hướng cực kỳ phức tạp: chúng dựa trên XML, và có các high assurance features khiến chúng trở nên khó hiểu và triển khai.
Hiện nay, các giao thức mới, OAuth, OpenID Connect, dựa trên HTTP đơn giản và JSON - một định dạng hợp lý và đơn giản - chúng dựa nhiều vào thực tế là mọi thứ diễn ra trên các secure channels. Điều này làm đơn giản hóa rất nhiều thứ, cùng với việc cắt giảm những thứ khác, nó làm cho các giao thức mới dễ tiếp cận hơn và ít nhất là dễ đọc hơn đối với các developers.
Tuy nhiên, chúng ta không thực sự nói về Harry Potter một câu truyện thú vị để đắm mình và cày hết từng tập của nó. Việc cày qua 69 trang ngôn ngữ kỹ thuật, chẳng hạn như các trang cấu thành đặc tả OpenID Connect Core, là một công việc khá khó khăn.
Nếu bạn đã và đang làm việc trong lĩnh vực ID, bạn sẽ thấy mình phải tham khảo chi tiết các đặc tả, lặp đi lặp lại, và cần chú ý từng tý một - những tài liệu đó rất khó hiểu và mơ hồ, thường thì sẽ không có ví dụ rõ ràng đi theo. Và chỉ thực sự hiểu khi bạn gặp phải vấn đề với nó trong quá trình làm việc thực tế.
Thực sự có rất nhiều đặc tả như vậy, ngay cả khi bạn giới hạn phạm vi chỉ đến một hoặc hai bước từ các đặc tả lõi của OpenID Connect và OAuth2. Tất cả các đặc tả mà bạn thấy là OAuth, OpenID, JWT, JWS, JWK, etc.
Lý do chính mà tôi đang chỉ cho bạn điều này là để xóa tan quan niệm mà rất nhiều người thực sự thích tin rằng chỉ cần đọc đặc tả là đủ. Yeah, thực tế khác hoàn toàn.
Tôi ở đây để giúp các bạn điều đó, ngoài việc tìm hiểu về lí thuyết, chúng ta sẽ cùng nhau xây dựng những ứng dụng thực tế và chỉ ra những cases thường gặp, sau đó mổ xẻ các chi tiết trong đặc tả để hoàn toàn làm chủ nó.
OAuth2 Roles
Hãy bắt đầu với một vài định nghĩa mà tôi nghĩ chúng ta cần trước khi bắt đầu hành trình. OAuth2 và OpenID Connect định nghĩa một số khái niệm cần thiết để mô tả những gì đang diễn ra trong các identity transactions.
Đặc biệt, OAuth2 giới thiệu một số roles tiêu chuẩn mà các tác nhân khác nhau có thể đóng trong bối cảnh của một identity transactions. Vì OpenID Connect được xây dựng trên OAuth2, nó cũng thừa hưởng những roles đó.
- Resource owner: đơn giản là người dùng. Hãy nghĩ về kịch bản LinkedIn và Gmail trong bài trước: resource mà LinkedIn muốn truy cập là hộp thư Gmail của người dùng; do đó, người dùng trong kịch bản là resource owner.
- Resource server: là người bảo vệ resource, người gác cổng mà bạn cần phải vượt qua để có được quyền truy cập. Trong kịch bản mô hình của chúng ta, resource server là bất kỳ cái gì bảo vệ API mà LinkedIn gọi để liệt kê các liên hệ và gửi email thay mặt resource owner.
- Client: có lẽ là thực thể nổi bật nhất đối với các nhà phát triển. Từ quan điểm của OAuth2, client là ứng dụng cần có quyền truy cập vào resource. Trong ví dụ của chúng ta, đó sẽ là ứng dụng web LinkedIn.
- Authorization server: như đã được đề cập trong bài trước đó, Giới thiệu về Digital Identity, là tập hợp các endpoints được sử dụng để thực hiện việc xác thực và uỷ quyền.
Authorization và token endpoints được định nghĩa trong OAuth2 Core. OpenID Connect bổ sung chúng với discovery endpoint, đây là một standard endpoint cung cấp các thông tin liên quan đến authorization server.
Ví dụ, nó sẽ liệt kê thông tin như địa chỉ của authorization & token endpoint. Thông tin quan trọng khác mà discovery endpoint cung cấp là key mà OIDC clients nên sử dụng để verify các token được phát hành bởi authorization server, và nhiều thứ khác nữa.
OAuth2 Grants and OIDC Flows
Những thứ phức tạp nhất trong bối cảnh của OAuth2 và OpenID Connect thường là grants.
- Grants chỉ là tập hợp các bước mà một client sử dụng để lấy một loại thông tin xác thực nào đó từ authorization server, nhằm mục đích truy cập vào một resource nào đó.
OAuth2 định nghĩa một số lượng lớn các grants vì mỗi grant tận dụng khả năng của một loại client khác nhau để kết nối với authorization server theo cách riêng của họ, và cũng tuỳ vào mức độ bảo mật mà một client cần.
Grants cũng phục vụ mục đích giải quyết các kịch bản khác nhau, chẳng hạn như kịch bản mà truy cập được thực hiện thay mặt cho người dùng so với việc thông qua các quyền hạn được gán trực tiếp cho client và nhiều hơn nữa.
Dưới đây là một số grants ban đầu được định nghĩa bởi OAuth2, tuy nhiên tôi sẽ không nói chi tiết về chúng trong bài này, chúng ta vẫn còn một số thông tin khác trước khi thực sự chạm đến chúng.
- Authorization Code
- Implicit, Resource Owner Credentials
- Client Credentials
- Refresh Token
OpenID Connect cũng giới thiệu một cái mới gọi là Hybrid, nó là sự kết hợp của hai OAuth2 grants cụ thể thành một luồng duy nhất.
Ngoài các grants được định nghĩa bởi các đặc tả OAuth2 và OpenID Connect, nhóm làm việc OAuth2 tại IETF và OpenID Foundation liên tục sản xuất các phần mở rộng độc lập, được thiết kế để giải quyết các kịch bản mà không được xem xét ban đầu bởi các đặc tả cốt lõi, hoặc được coi là quá cụ thể để được đưa vào.
Conclusion
Một lần nữa, việc nắm rõ các roles trong OAuth2 và OIDC là rất quan trọng nếu không muốn nói là bắt buộc, nó sẽ giúp chúng ta hiểu và triển khai các grants một cách dễ dàng và thuận tiện hơn.
Tài liệu tham khảo:
- The OAuth 2.0 Authorization Framework: RFC 6749
- OpenID Connect Core
- OAuth2 and OpenID Connect: The Professional Guide
Again, nếu bạn thấy bài viết này hữu ích, hãy cho mình một upvote và follow để mình có thêm động lực viết những bài sau tốt và chất lượng hơn! Thank you!