Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Handling SSO/Web_Auth flow/tokens within the Openvpn-Client

Đang mở
  • Có gì không ổn?
#369 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
cpp
Lĩnh vực
authentication, networking, security

Hướng nghiên cứu

Bắt đầu với doc/webauth.md và phần về WEB_AUTH trong management-notes.txt, sau đó so sánh luồng phía máy chủ được mô tả ở đây với phương pháp OAuth2/PKCE cục bộ phía máy khách được đề xuất. Một kết quả hữu ích sẽ là quyết định của các maintainer về tính khả thi, các vấn đề cần cân nhắc về bảo mật và việc có muốn hỗ trợ chính thức cho cấu hình máy khách và máy chủ hay không.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Hi,

This is a general question, no bug report. I've been digging into the possibilities to use OpenIDConnect (oidc) to authenticate a User at an openvpn-server.

I'm aware of the supported method of using an AUTH_PENDING control message, supplying a redirect-url within a following INFOMSG that triggers the client to open a browser and continue Authentication using a OAuth2/oicd Flow (WEB_AUTH and management-interface).

AFAICT this method always relies on some (openvpn-)server-side https-service that is used as a redirect-uri for the authorization-code flow, e.g. the openvpn-auth-oauth2 plugin, i.e., receiving id_token, refresh_token at the server side and logging the user in from "there".

I'm also aware of the various ways to send an additional challenge to the client using AUTH_PENDING with crtext or the (older?) mechanism of using sending back an error containing the CRV1:<flags>:<state>:<b64(user)>:<challenge-text>. Those are restricted to a strictly textual challenge-response, though.

I was wondering why there seems to be no support for a solution (in the openvpn repos, at least) that only involves the client (be it a "native/desktop app" or a "mobile app" in OAuth2 terms) completing the authorization-code flow (with PKCE) and using the thereby obtained id_token to authenticate with the openvpn-server, in lieu of a password. The redirect-uri for that scenario could either be a loopback addr (http://127.0.0.1:<port>) for desktop or a claimed https:// URI for mobile.

I am aware that it is possible to implement a plugin and custom client (or even a wrapper around the existing client, as was done here) that implements the described "client-local approach". However it seems like a nice thing to have the "official" openvpn-server and client implementing a mechanism and configuration support for oidc in a way that the openvpn-server defines the parameters and the client takes care of the OAuth2-Flow and mangement of the id_token (and in extension, refresh_token etc.).

Am I missing something that makes that approach unfeasible or unsafe? Is it something that has been discussed and been discarded for this or that reason? Or am I overlooking something and it's ready to go and I just can't find it?

Kind regards,
Andreas

Ngôn ngữ chính
C++
Star
1.2k
Fork
467
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenVPN/openvpn3

Tất cả issue của OpenVPN/openvpn3

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.