OpenID Connect - 從第三方啟動登入
OpenID Connect Core 1.0 - 4. Initiating Login from a Third Party 裡，定義了一個 RP 的 URI 路徑規範，是在處理第三方啟動登入的情境。
註：RP 指的是 Relying Party，也就是 OAuth2 Framework 裡的 Client 角色.
閱讀原文
原文一開頭，有明確說明情境為何：
In some cases, the login flow is initiated by an OpenID Provider or another party, rather than the Relying Party.
因 OpenID Connect 的登入流程裡，是由 RP 發起登入請求，而最終會回到 RP 註冊好的 redirect_uri。但有些情境下，登入流程不是由 RP 發起的。有可能是 OP（OpenID Provider）發起，也有可能是其他 RP 或其他外部服務發起的。
比方說，由 OP 寄送信件，然後信件內容是引導使用者登入指定 RP，這時就適合使用此規範。
接著原文有簡單說明如何處理這一類的情境：
In this case, the initiator redirects to the RP at its login initiation endpoint, which requests that the RP send an Authentication Request to a specified OP. This login initiation endpoint can be a deep link at the RP, rather than a default landing page.
RP 要實作一個登入啟動端口（login initiation endpoint），而這個端口的任務就是發送 Authentication Request 給指定的 OP。
以上面提到的信件例子，可以在信裡放這個登入啟動端口的連結，並指定 OP 即可。
文件定義了這個端口需要實作哪些參數：
| Parameter | Required | Description |
|---|---|---|
| iss | REQUIRED | 一個可以標識要對哪個 OP 發送請求的字串，只要 RP 能分辨即可 |
| login_hint | OPTIONAL | 登入帳號提示，與 Authentication Request 的 login_hint 意義相同，RP 需直接轉傳給 OP |
| target_link_uri | OPTIONAL | 指驗證後 RP 要將使用者導去哪 |
文件又提到了這些參數可以用 GET 也可以用 POST 傳遞，相對來說，代表 RP 會需要定義這個端口可以接收 GET / POST 請求。
如果有定義其他參數，也可以發送；而其他未定義的參數一律忽略。
最後就是要注意像是 Clickjacking 攻擊，參考 RFC 6819 - 4.4.1.9 Threat: Clickjacking Attack against Authorization 可以了解更多。
實務上會遇到的問題
工程師都了解，有規格要實作都很簡單，但沒有規格要自定義時，會很傷腦筋，要思考各種情境對系統的影響。
這個規範短而簡單，但裡面缺少了幾個必要細節是需要自己定義的。以下為我目前實作遇到的問題，以及思考方向做為參考。
當 iss 給不合法的值
因 iss 為必填，但又得到不合法的值，這時該如何引導使用者？或者是完全沒 iss 參數的時候，又該怎麼辦？
這兩個問題是類似的，這個情境有三個選擇：
- 回應錯誤頁，如 4xx 系列的錯誤頁。
- 轉導到 RP 預設的首頁。
- 忽略錯誤使用 RP 預設的
iss啟動登入流程。
選項 1 或 2 是類似的，讓使用者可以自己選擇預設的 iss 登入，但 2 相較更合理，因為這個情境顯示錯誤頁並沒有什麼意義。
當 RP 有登入狀態的時候
當 RP 已經有登入狀態的時候，又來一個登入請求時，該怎麼辦？
這種狀態有兩種情境：
- 前一個登入狀態的 iss 與新的 iss 相同
- 前一個登入狀態的 iss 與新的 iss 不同
不同商業需求，可能會有不同的處理方法，但大概不外乎兩種選擇：
- 忽略登入請求，直接使用 RP 原有的登入狀態。
- 無條件清除 RP 的登入狀態（指登出），接著再重新啟動 RP 的登入流程。
一般選項 1 是比較合理的，一般服務在已登的狀態下，再強制開啟登入畫面時，通常也不會把原有的登入狀態清除。如果要清除狀態，可以新增客製化參數，並搭配 prompt=login 參數達成類似的效果。
延伸閱讀：使用 prompt 參數