Rời Auth0: thứ gì thực sự chuyển đi, và một thứ duy nhất họ sẽ không trao cho bạn

Phần lớn các nhóm rời Auth0 không phải vì họ ghét nó. Họ rời đi vì hóa đơn tăng vọt, hoặc vì SAML và SCIM hóa ra nằm sau một bậc doanh nghiệp tính phí theo từng kết nối, và mỗi liên kết SSO của khách hàng mới lại làm đồng hồ đếm tăng lên. Rồi họ ngó tới việc thực sự di chuyển nhà cung cấp danh tính của mình, kết luận rằng nghe có vẻ đáng sợ, và ở lại thêm một năm nữa.

Nó ít đáng sợ hơn vẻ ngoài. Đây là những gì một cuộc di chuyển Auth0 thực sự bao gồm (những phần nhàm chán, những phần rắc rối, và một phần thực sự khó) để bạn có thể tự đánh giá.

Có những gì trong tenant Auth0 của bạn

Một số thứ phải đáp xuống một nơi nào đó mới:

• Ứng dụng → các client OAuth/OIDC. Callback, URL đăng xuất, origin được phép, các loại grant, và client secret. Máy móc.
• API (resource server) + scope → các audience và scope, được nối với các client sử dụng chúng (Auth0 theo dõi điều đó dưới tên «client grants»).
• Vai trò và các phân công của chúng → vai trò + liên kết vai trò theo từng người dùng.
• Kết nối → kết nối doanh nghiệp (OIDC/SAML), mạng xã hội, và cơ sở dữ liệu. OIDC doanh nghiệp ánh xạ gọn gàng sang một nhà cung cấp liên kết; phần còn lại bạn cấu hình lại.
• Người dùng → hồ sơ, metadata, và các danh tính xã hội/doanh nghiệp đã liên kết.

Về nguyên tắc, không có gì trong số đó là khó. Sự lo lắng đến từ ba thứ cụ thể.

Ba thứ khiến người ta lo lắng

1. Giữ danh tính ổn định. Người dùng của bạn được tham chiếu bằng sub của họ (và các ứng dụng của bạn bằng client_id) ở khắp nơi: refresh token do các ứng dụng phía sau nắm giữ, các dòng SCIM trong IdP của khách hàng, ID người dùng lưu trong cơ sở dữ liệu của chính bạn. Nếu một cuộc di chuyển sinh ra ID mới, tất cả những thứ đó sẽ hỏng một cách âm thầm. Cách khắc phục dễ phát biểu và thiết yếu phải làm đúng: giữ user_id của Auth0 làm sub và giữ client_id y nguyên. Khi đó không có gì ở phía sau nhận ra.

2. Mật khẩu, phần thực sự khó. Management API của Auth0 không bao giờ trả về các hash mật khẩu. Đó là chính sách cố ý của Auth0, không phải lỗ hổng trong công cụ của bạn. Bạn có hai con đường trung thực:

• Yêu cầu Auth0 xuất hàng loạt có hỗ trợ từ support, cách này cho bạn một tệp NDJSON chứa hash bcrypt của từng người dùng. bcrypt có tính khả chuyển: bất cứ thứ gì xác minh được bcrypt đều có thể tiếp nhận các hash đó y nguyên, và người dùng của bạn không phải đặt lại gì cả.
• Hoặc bỏ qua hash hoàn toàn và để người dùng đặt mật khẩu mới ở lần đăng nhập đầu tiên. Không có gì bị «mất» (vốn chẳng có hash nào để mang theo) nhưng đó là một bước hiển thị với người dùng của bạn.

Không có API tự phục vụ nào cho các hash. Ai bảo bạn rằng một lần xuất Auth0 chỉ một cú nhấp đã bao gồm mật khẩu mà không cần tệp support đó thì đang nói chuyện viển vông.

3. Trần 1.000 người dùng. API liệt kê người dùng của Auth0 trả về tối đa 1.000 người dùng. Với một tenant lớn hơn, tệp xuất hàng loạt (chính tệp mang theo các hash) mới là nguồn người dùng thực sự và đầy đủ, chứ không phải API trực tiếp.

Biến nó thành một cú nhấp

Đây là những gì chúng tôi đã xây dựng vào Authagonal. Bạn trỏ trình nhập tới một ứng dụng machine-to-machine của Auth0 (chỉ scope đọc), và nó:

• Chạy trước một bản xem trước chỉ đọc: nó đếm từng ứng dụng, API, vai trò, kết nối và người dùng mà nó sẽ nhập, đồng thời gắn cờ bất cứ thứ gì cần lưu ý. Không có gì được ghi cho đến khi bạn xác nhận.
• Đưa các ứng dụng, scope/audience của API, vai trò + phân công, người dùng + metadata, và các kết nối OIDC doanh nghiệp sang, giữ nguyên sub và client_id để các token và tham chiếu hiện có tiếp tục phân giải được.
• Băm lại các client secret của Auth0 (đọc được dạng văn bản thuần) để các ứng dụng của bạn tiếp tục xác thực mà không cần xoay vòng.
• Nhập các hash mật khẩu bcrypt y nguyên nếu bạn cung cấp tệp xuất, và tệp đó cũng nâng trần 1.000 người dùng. Không có bản xuất? Người dùng đặt mật khẩu ở lần đăng nhập đầu tiên.

Và vì các tính năng doanh nghiệp (SAML, SCIM, MFA, nhật ký kiểm toán, tên miền tùy chỉnh) được bao gồm trong mọi gói thay vì tính phí theo từng kết nối, thứ đã đẩy bạn ra cửa không hề chờ bạn ở phía bên kia.

Một ghi chú ngoài lề về việc kiểm thử di chuyển

Chúng tôi kiểm thử trình nhập trên một cơ sở dữ liệu thực, đã được seed, không phải mock, và nó đã chứng tỏ giá trị. ASP.NET Identity lưu LockoutEnd dưới dạng datetimeoffset, và đọc nó bằng GetDateTime() sẽ ném lỗi với kiểu đó. Chỉ một người dùng bị khóa thôi cũng đủ làm hỏng toàn bộ một lần nhập. Bạn chỉ phát hiện ra điều đó khi chạy trình nhập thật trên dữ liệu thật. Nếu bạn đang đánh giá bất kỳ công cụ di chuyển nào, hãy hỏi nó được kiểm thử ra sao: «chúng tôi mock API nguồn» không giống với «chúng tôi chạy nó trên một tenant đã có dữ liệu».

Nếu bạn đang ngắm nghía lối ra

Cuộc di chuyển nhàm chán hơn bạn lo sợ (xem trước nó, giữ các ID của bạn, quyết định con đường mật khẩu) với ràng buộc thực sự duy nhất là việc xuất hash của Auth0. Nếu bạn muốn xem những gì sẽ chuyển sang từ tenant của mình, bản xem trước là chỉ đọc và cho bạn thấy mọi thứ trước khi bạn xác nhận.

→ Di chuyển khỏi Auth0