Số nhận dạng OpenID của Google khác nhau tùy thuộc vào tên miền "người tiêu dùng". Làm thế nào để tránh các vấn đề nếu tên miền cần thay đổi?

Question

Tôi hiện đang thử nghiệm triển khai OpenID và tôi nhận thấy rằng Google sẽ gửi một số nhận dạng khác nhau cho tên máy chủ/tên miền khác nhau, ngay cả đối với cùng một người dùng. Ví dụ: Google sẽ gửi số nhận dạng khác khi trang web yêu cầu là localhost, so với số nhận dạng họ gửi khi trang web yêu cầu là 127.0.0.1 cho cùng một người dùng.

Lưu ý: Tôi chưa thực sự thử nghiệm điều này bằng cách sử dụng tên miền công cộng, nhưng tôi không thể thấy lý do hành vi sẽ khác biệt.

Quan tâm của tôi đối với hành vi của Google là nếu chúng tôi chọn thay đổi tên miền trang web của mình trong tương lai, thì người dùng sẽ không còn có thể đăng nhập vào trang web bằng OpenId của Google làm nhà cung cấp danh tính. Điều này có vẻ là một vấn đề lớn. Tôi có thiếu một cái gì đó, hoặc là tất cả các trang web tiêu thụ OpenID phải đối mặt với vấn đề tiềm năng này?

Tôi cũng đã thử nghiệm điều này với MyOpenId, nhưng mã định danh mà MyOpenId tạo là cố định, do đó, điều này sẽ không là vấn đề với chúng.

Answer 1

Hãy xem Google OpenID most important technical issue. Một số infos ở đó. Về cơ bản một liên kết được lấy từ phần tài khoản của stackoverflow.com;)

-sa

Answer 2

Dường như các URL OpenID trả về bởi Google phụ thuộc vào openid.realm giá trị được sử dụng. Ngoài ra, tôi vừa thử quy trình OpenID với một lĩnh vực được đặt thành http://MYREALM và openid.return_to được đặt thành http://localhost/openid.php, nhưng đã nhận được Yêu cầu không hợp lệ HTTP 400. Rõ ràng, Google kiểm tra rằng lĩnh vực có cùng tên miền (và có thể là cổng) là URL "quay lại".

Một ý tưởng cho công việc xung quanh là lưu trữ địa chỉ Gmail được liên kết với OpenID. Bất cứ khi nào bạn yêu cầu Google OpenID, luôn yêu cầu địa chỉ email của người dùng thông qua loại http://axschema.org/contact/email của Attribute Exchange. Nếu bạn thay đổi tên miền, bạn có thể liên kết URL OpenID mới với tài khoản của họ dựa trên địa chỉ email.

Lưu ý: Đó là bắt buộc mà bạn xác minh chữ ký HMAC-SHA1. Nếu không, bất kỳ ai cũng có thể "quay lại" hành động kiểm tra OpenID của ứng dụng web của bạn với địa chỉ email được xây dựng, cho phép họ tiếp quản tài khoản của ai đó nếu họ biết địa chỉ Gmail của mục tiêu.

Khi người dùng đang đăng nhập bằng tài khoản Google của họ lần đầu tiên sau khi chuyển đổi, quá trình chuyển đổi là:

1. Gửi yêu cầu POST để https://www.google.com/accounts/o8/ud với các thông số sau:

    
   +---------------------+----------------------------------+ 
   | openid.ns   | http://specs.openid.net/auth/2.0 | 
   | openid.mode   | associate      | 
   | openid.assoc_type | HMAC-SHA1      | 
   | openid.session_type | no-encryption     | 
   +---------------------+----------------------------------+ 
   

   (thay thế openid.realm=http://NEWREALM nếu thích hợp)

   Câu trả lời sẽ giống như sau:

    
   ns:http://specs.openid.net/auth/2.0 
   session_type:no-encryption 
   assoc_type:HMAC-SHA1 
   assoc_handle:B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq 
   expires_in:46800 
   mac_key:F5XUXvoYutLvFv4IzJS0diytLmbe 
   

2. Với sự chuyển hướng để URI Dịch vụ, https://www.google.com/accounts/o8/ud, chế độ 'checkid_setup', hãy chắc chắn để gửi assoc_handle mà trước đó đã thu được cũng như yêu cầu địa chỉ email của người dùng thông qua thuộc tính Exchange.Nói cách khác, hãy chắc chắn để gửi, các thông số bổ sung sau đây:

    
   +----------------------+----------------------------------------------------------+ 
   | openid.assoc_handle | B5hJNa39Cl39BXSOKMqkPpk03rJmE0GI6EhHBkvfLOBFAMMQX67HjuFq | 
   | openid.ns.ax   | http://openid.net/srv/ax/1.0        | 
   | openid.ax.mode  | fetch_request           | 
   | openid.ax.type.email | http://axschema.org/contact/email      | 
   | openid.ax.required | email             | 
   +----------------------+----------------------------------------------------------+ 
   

   Các "trở lại" yêu cầu sẽ bao gồm các thông số quan trọng openid_signed, openid_sig, và openid_ext1_value_email.

3. Theo dõi the OpenID Authentication 2.0 Specification's procedure for generating the signature. Nếu mã hóa base64 của chữ ký HMAC-SHA1 không giống như giá trị openid_sig, thì chữ ký không hợp lệ. Lưu ý rằng khóa MAC trong ví dụ này là F5XUXvoYutLvFv4IzJS0diytLmbe. Sử dụng bất kỳ máy chủ nào của Google được gửi lại với yêu cầu liên kết.

 

Google's Federated Login documentation page states rằng http://axschema.org/contact/email "[r] equests địa chỉ gmail của người dùng". Có lẽ, khi Tài khoản Google được tạo thì địa chỉ email "Gmail" đã được sửa. Tuy nhiên, nếu giả định này không hợp lệ, thì không an toàn khi sử dụng quy trình này vì người dùng độc hại có thể thay đổi địa chỉ email của họ khi được Dịch vụ đăng nhập liên kết trả lại cho bất kỳ địa chỉ email nào của tài khoản mà họ muốn ăn cắp.

Để an toàn, trước khi kích hoạt OpenID mới, hãy gửi yêu cầu xác minh email đến địa chỉ email. Liên kết xác minh sẽ chứa một nonce được liên kết với OpenID mới. Khi liên kết được nhấp, OpenID mới sẽ được liên kết đầy đủ với tài khoản của người dùng khi biên lai của nonce sẽ xác minh liên kết giữa địa chỉ email và URL OpenID mới.

Xem thêm: openid.sig -- How is it generated?

Answer 3

Có một công việc khác có thể xảy ra xung quanh. Khi thực hiện yêu cầu xác thực gián tiếp (chuyển hướng đến URI dịch vụ), hãy gửi URL cũ OpenID làm giá trị của các thông số openid.claimed_id và openid.identity ngay cả khi lĩnh vực được đặt thành lĩnh vực mới.

Trên máy phát triển của tôi, tôi có tên miền 'thiscomputer' được đặt tên là 127.0.0.1. Khi tôi yêu cầu xác thực từ nhà cung cấp OpenID của Google, vương quốc 'http: // thiscomputer' và openid.identity và openid.claimed_id cả các thiết lập để http://specs.openid.net/auth/2.0/identifier_select, tôi đã trở lại một cái gì đó như:

https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ

sau đó tôi yêu cầu xác thực từ OP, vương quốc 'http : // localhost 'và openid.identity và openid.claimed_id cả hai được đặt thành http://specs.openid.net/auth/2.0/identifier_select. Tôi đã trở lại một cái gì đó như:

https://www.google.com/accounts/o8/id?id=VGwSBXNwzPQk-puNdfZl4tP-s7JNHPA3WmMHozHJ

sau đó tôi yêu cầu xác thực từ OP, vương quốc 'http: // localhost' và openid.identity và openid.claimed_id cả các thiết lập để https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ (bản sắc OpenID cho tài khoản Google của tôi khi vương quốc là 'http : // thiscomputer '). Tôi đã quay lại:

https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ

Tức là, tôi đã lấy lại cùng một URL nhận dạng OpenID khi cõi 'http: // thiscomputer'. Do đó, mặc dù tôi đã "di chuyển" ứng dụng web dựa trên OpenID của tôi từ 'máy tính này' sang 'localhost', tôi vẫn có thể sử dụng URL nhận dạng OpenID cũ.

Giải pháp này hoạt động miễn là bạn biết URL nhận dạng OpenID cũ của người dùng, có lẽ do URL được lưu trữ trong cookie.

Một lưu ý: Tôi cố gắng thiết lập openid.identity và openid.claimed_id để giá trị khác nhau (ví dụ như một là http://specs.openid.net/auth/2.0/identifier_select trong khi người kia là https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ hoặc một là https://www.google.com/accounts/o8/id?id=VGwSBXN7Q00X4G9CTAsLPMJ3m6JaPljpkrURAUZJ và thứ hai là https://www.google.com/accounts/o8/id?id=VGwSBXNwzPQk-puNdfZl4tP-s7JNHPA3WmMHozHJ), nhưng dịch vụ OP của Google đáp lại bằng "Trang bạn yêu cầu không hợp lệ . "