# 2020-09-01 novさん

## 相談1

IdPのAuthentication URLをブックマークしてしまう人が一定数いる。
ブックマークからスタートした場合、RPに戻ったところでCSRFになってしまう。
いい感じにできないもんかなあ。

IdP側ではエラーにできない。
RP側でCSRFエラーにせざるをえない。
CSRFのときのエラーページをちゃんと用意してユーザーのアクションを要求するしかないかなあ。

- PCだったらpopupでIdPを呼び出すようにすればブックマークすること自体を防ぐことはできる。
- popupのUX
- PCならRPを完全に離れることを防止できる
- スマホの場合は新規タブで開いちゃう
- 戻るボタンを押したらタブを閉じる、とかもできなくはない。
- Safariはブラウザの戻るボタンでタブを閉じることができるらしい。
- target=_blank とかで開いた場合？
- display=popupを使わない選択肢
- IdP側でUAとかdisplay size見て可変にすれば display パラメータ使わなくてもいい
- RP は `window.open` で呼び出しする
- ただし、callback は open されたウィンドウに戻ってくる
- post_message とかでも
- RPがcallbackがんばらなくてもいいようにするには
- web message
- https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00
- モバゲーがやってた
- リダイレクトするとjsがリロードされてしまう（色んなイベントが発火してしまう、stateを復元する手間がある）
- いまでもSPAの場合popoup使いたくなるはず

## 相談2

IdPのログインセッション
1st Party RPのログインセッション（IdPはOP1つのみ）

どう考えるといいか

### 完全同期するのであれば

- cookie共有

### これはやってる

- 特定のイベント（パスワードリセットとか）が起きた場合、RP側のセッションも無効化したい
- ユーザーがRPを明示的にログアウトした場合、そのブラウザのOPもログアウトしたい

### memo

- RPのセッションがOPのセッションよりが長いのはよくなさそう
- RPはできる限り短くして、頻繁にIdPに認証しにいくほうが良さそう
- IdPがリスクベースで再認証したりとかすればRPはなにも考えなくてもいい
- RPはこの期間ならセッション盗まれていても許容する、みたいな時間にしておけばいい
- ITPの話でなんか気にすることあるだろうか

RPのリスク次第ではある

#### IdPのほうが長い場合

- RPがセッションタイムアウトしたとしても、1クリックすればログインできちゃう。
- 許容できない場合
- max_ageパラメータを使うとか
- OPはmax_ageを過ぎていれば再認証
- RPはID Tokenのauthtimeを検証（max_ageパラメータを削除されている可能性があるので）

#### そもそもなんでセッションを切るべきなのか

- セッションが漏れる
- 端末共有
- 端末自体をだれかに使われる

#### memo

- B2Cだと例えば最終アクセスからN日とか
- B2Bだと1日1回ログインを強制させたい、というニーズもある
- 退職者とか部署異動とかによる権限変更をIdPから取り直したい
- 共有PC
- ログアウト徹底してもらう
- ブラウザ終了してもログインしたままにする、的なチェックボックスを用意する？
- スマホだとこれはいつなんだろう？
- アプリのプロセスが殺されたときとか再起動とか？

#### ポリシー

IdPが決めるというよりは、会社のセキュリティ統括的なところで決めるべき。

- リスクベース認証
- セッションを作るとき
- IdPがチェックすればいい
- セッション継続の妥当性
- 重要な操作をする前にIdPに再認証させる
- ユーザーのフローを記録しておいて、明らかに人間ではない操作とかを弾いたり

・IPアドレス見て、場所が大きく変わったとかを検知
・UserAgentが変わった
こういうのをIdPがチェックする、みたいなのは責務から外れていく。

## 相談3

BackendありのSPA
https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-06
https://aaronparecki.com/2020/07/22/7/

JavaScript Applications with a Backend

> The Application Server stores this access token itself and establishes its own cookie-based session with the Browser application. The Application Server can store the access token either server-side, or in the cookie itself.

後半のセンテンス。
「The Application Server can store the access token either server-side, or in the cookie itself.」

cookieにストアしたい理由はなんだろう。
DBとかがないアプリケーションサーバを想定している？

ブラウザがリソースサーバーにアクセスしたいときは、直接ではなくアプリケーションサーバを経由する。
はい。

> Note that if the access token is used as the session identifier, this exposes the access token to the end user even if it is not available to the JavaScript application, so some authorization servers may wish to limit the capabilities of these clients to mitigate risk.

ブラウザとアプリケーションサーバの間のセッションはcookieじゃなくてアクセストークンつかっても良い。
ここでのアクセストークンはAuthorization Serverが発行するアクセストークンではなく、アプリケーションサーバが発行する独自のアクセストークンだよね。

### どっちを使うべきか。

- cookie
- XSSには強い（オフラインでの攻撃は防げる）
- CSRFには
- access token in localstorage
- XSSで漏れる

### ITP絡んだりする？

- Safariは7日間UserInteractionがない場合localStorage消す
- ServerSideで設定したcookieであれば消されない
- ただし、Tracker判定されると消される

### Native App と SPA

- Native App
- XSSがない
- セキュアなストレージがある

PWA

## 相談4

KYC（eKYC）やることになりそう。

個人のKYC
法人のKYC

なにから要件整理・設計していけばいいか。

- 銀行等の金融機関
- 法律（はんしゅうほう）がある
- どういうドキュメント（登記簿等）をもらって、どの属性を確認しないといけないかとか
- 貸し倒れするリスクの確認とかっては金融機関独自の要件

- 1人の人間が複数のMFIDをもつことを許容している
- etc