1 việc làmOauth

HOT JOB
Backend Developer (Java, Spring Boot)
Ngân hàng TMCP An Bình (ABBANK)
Middle, Senior
Quận Đống Đa, Hà Nội
(In Office)
Mức lương cạnh tranh, phản ánh trực tiếp kỹ năng và kinh nghiệm của ứng viên (chi tiết sẽ được thảo luận trong buổi phỏng vấn).13 ngày nghỉ phép linhhoạt, bao gồm ngày sinh nhật và các dịp quan trọng khác.
Bảo hiểm đầy đủ theo luật lao động, cùng với ABBANK CARE - chương trình phúc lợi bổ sung đặc biệt dành cho ABBankers.
Lãi suất vay ưu đãi - Quyền lợi đặc biệt dành cho nhân viên ABBANK.
Java NoSQL Restful Api Java Spring Boot Oauth
Đăng 3 ngày trước

Bài viết liên quan

Xem tất cả

Hiện thực OAuth Resource Server sử dụng Spring Security OAuth2 Resource Server

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh Resource Server trong OAuth2 được sử dụng để protect việc truy cập đến các resources, APIs. Nó sẽ validate access token được truyền bởi Client Application, với Authorization Server để quyết định xem liệu Client Application có quyền access tới các resources, APIs mà nó muốn hay không? Trong bài viết này, mình hướng dẫn các bạn cách hiện thực OAuth Resource Server sử dụng Spring Security OAuth2 Resource Server các bạn nhé! [irp posts="41385" name="Authorization Code grant type với Proof Key for Code Exchange (PKCE) trong OAuth 2.1"] [irp posts="40402" name="Giới thiệu về OAuth"] Xem thêm các chương trình tuyển dụng Spring trên TopDev Đầu tiên, mình sẽ tạo mới một Spring Boot project với Spring Web, Spring Security OAuth2 Resource Server để làm ví dụ: Kết quả: Đầu tiên, mình sẽ tạo mới một RESTful API đóng vai trò là resource mà chúng ta cần resource server protect. Nội dung của API này đơn giản như sau: package com.huongdanjava.springsecurity; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation. [...]

Đọc thêm

Sự khác nhau giữa OpenID Connect và OAuth 2.0

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh Mình đã giới thiệu với các bạn về OAuth 2.0 và OAuth 2.0 chỉ là một framework liên quan đến Authorization, nghĩa là nó chỉ định nghĩa những resources nào mà một Client Application có thể sử dụng trong access token, để khi request tới Resource Server, Resource Server sẽ căn cứ vào access token để quyết định có cho phép Client Application access tới resource hay là không? [irp posts="41385" name="Authorization Code grant type với Proof Key for Code Exchange (PKCE) trong OAuth 2.1"] [irp posts="40239" name="Building Microservices Application - Phần 3: Xác thực API bằng Oauth 2.0"] Thế nhưng nói về security, các bạn có thể biết, chúng ta còn có cả authentication và OpenID Connect là một extension của OAuth 2.0 được giới thiệu để bổ sung phần authentication này. Sử dụng OpenId Connect thì nội dung của access token mà Client Application sử dụng để request tới Resource Server sẽ bao gồm cả thông tin user đang grant quyền truy cập tới những resources này. Trong OpenID Connect thì Authorization Server được gọi là Identity Provider. Identity Provider sẽ đảm nhận chức [...]

Đọc thêm

Các loại Client Types trong OAuth 2.0

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh Trong OAuth 2.0, chúng ta có thể có nhiều loại Client Application khác nhau mà người dùng có thể sử dụng để access tới các resources của resource server. Ví dụ như chúng ta có native mobile application, web application bao gồm cả Single Page Application, console hay backend application, … Những Client Application này sẽ cần phải đăng ký với Authorization Server và sử dụng thông tin Client ID được cung cấp bởi Authorization Server để lấy access token. Một số grant type trong OAuth 2.0 đòi hỏi chúng ta phải cung cấp cả Client Secret, cái mà Client Application được Authorization Server cung cấp cùng với Client Id, ví dụ như grant type Client Credentials chẳng hạn. [irp posts="40402" name="Giới thiệu về OAuth"] [irp posts="8791" name="OAuth2 là gì? Tìm hiểu về OAuth2"] Không phải tất cả các Client Application đều có thể lưu trữ Client Secret một cách bảo mật. Ví dụ như Native mobile application hay Single Page Application. Vì thế, OAuth 2.0 định nghĩa 2 loại Client Types khác nhau bao gồm: các confidential clients và các public clients. Confidentials [...]

Đọc thêm

Authorization Code grant type với Proof Key for Code Exchange (PKCE) trong OAuth 2.1

Bài viết được sự cho phép của tác giả Nguyễn Hữu Khanh Các public client như Native mobile application or Single Page Application không thể lưu trữ Client Secret trong Authorization Code grant type một cách bảo mật được. Decode source của mobile application hay view source code của Single Page Application, chúng ta có thể xem được thông tin Client Secret này. Vì thế OAuth giới thiệu Proof Key for Code Exchange (PKCE) extension hỗ trợ cho Authorization Code grant type để giải quyết vấn đề này. Cụ thể như thế nào? Trong bài viết này, chúng ta sẽ cùng nhau tìm hiểu về Authorization Code grant type với Proof Key for Code Exchange (PKCE) trong OAuth 2.1 các bạn nhé! [irp posts="40239" name="Building Microservices Application - Phần 3: Xác thực API bằng Oauth 2.0"] [irp posts="8791" name="OAuth2 là gì? Tìm hiểu về OAuth2"] Ý tưởng của PKCE là sử dụng 1 cặp secret code bao gồm Code Challenge và Code Verifier, được generate bởi ứng dụng thứ ba hay còn gọi là Client Application. Client Application sẽ gửi Code Challenge đi cùng với request để lấy authorization code. Authorization server sẽ lưu Code Challenge này lại. [...]

Đọc thêm