プロダクトの認証認可下調べ

主に認証にフォーカスする

アーキテクチャ・micro services

組織

OAuth、OpenID の基本

情報が多いところ

実装と詳細、考え方

細かく言えば認証とログインは別のものであると捉えています。

一般的な認証というのは、「システムを操作している人物が確かにこの ID の持ち主であると確認すること」を指します。あえて言えば、認証というのはその「瞬間」のことを指します。

一方でログインは、「その結果をいつまで信頼するのかというポリシーを適用し、認証に期間を与えること」を指します。

認可という言葉は別の文脈で使われることがあります。その文脈では、「誰が何の権限を持っているか (who has what permissions)」という情報を扱うために認可という言葉を使います。これは、OAuth の文脈での認可「誰が誰に何の権限を与えるか (who grants what permissions to whom)」とは異なります。厄介なことに、このどちらも認可と呼ばれ、英語でも両方とも authorization という単語が使われます。

セキュリティ

Passwords must be checked against a database of compromised secrets such as Have I Been Pwnd:

スクリーニング

オープンリダイレクト

ライフサイクル

アカウントリカバリ

なぜパスワード認証をやめようと思うとリカバリーが不安になるのかに話を戻すと、このように１つの認証方式だけだと思っていた「パスワード認証」は既に複数の認証方式を並列にしている状態であり、一方で WebAuthn は単一の認証方式しか存在しないことが不安を感じる理由なのではないかと思うのです。

ガイドライン

Authentication and Lifecycle Management

Verifierは，オフライン攻撃に対して耐性をもった形式で記憶シークレットを保存するものとする(SHALL)．シークレットは， ソルトを追加したうえで適切な一方向の鍵導出関数を利用してハッシュされるものとする(SHALL)，鍵導出関数は，パスワード，ソルト，コストファクタを入力して，パスワードハッシュを生成する．例えばSP800-132で記載されているPBKDF2のようなApprove済みハッシュを用いてハッシュ化されるものとする(SHALL)．ソルト値は32ビット以上のランダム値で，承認済み(approved)の乱数生成器を用いて生成され，ハッシュ結果とともに記録される．少なくとも繰り返し10000回のハッシュ関数を適用すべきである(SHOULD)．...

バイオメトリクスの利用

バイオメトリックの比較は確率的なものであるが，他のAuthentication要素は決定的なものである．

単独での Authenticator としては認められない

バイオメトリクスは物理的なAuthenticatorを用いた多要素Authentication(something you have)の一部としてのみ利用されるものとする(SHALL)．

ID Federation

IDaaS, OSS

Okta

Keycloak

いくつかのプロダクト群からなり、OSS になっている。go 実装

Hydra

OAuth2/OIDC のフロー。ユーザ管理やログインの詳細は持たない

Kratos

Identity & User Management

現在は SSO / OIDC には対応していないように見える

go のライブラリ。 OAuth, MFA

WebAuthn, FIDO2

その他(公的)個人認証

各サービスのアカウント周りの仕様・挙動

Yahoo! JAPAN

アカウント登録は、SMS から始まる

Email でのログインもオプションで設定ができる

パスワードは設定しない

LINE

「パスワードでログイン」はOFFにできる

アプリ上でのパスワード変更: Face ID が要求される。現在のパスワードは必要ない。

他の端末でログインする場合は、ログイン済みの端末を用意して、ワンタイムコードかQRコードでログイン