Authentication
Overview
認証とは相手の身元を確認すること。
認証: Authentication AuthCやAuthNと略されることも リソースや権限には無関係 通信相手のID（もっというと属性）をなりすましでないと確信すること。
認証の3要素
コンピューターの世界も含め、現実世界で「認証」を行うための要素には以下の3つがある。
-
WHAT YOU ARE (inherence factor) 顔貌、声、指紋、署名など、その人自身を提示して、相手にアイデンティティを確認させる方法。 小さなコミュニティでは、お互いの顔や声を相互に知っているため、面と向かえば相手が誰かはわかりますね。 認証が完了する、ということです。
-
WHAT YOU HAVE (possession factor) 身分証、携帯電話等、その人だけが持っているものを提示することによって認証をします。ある程度コミュニティが大きくなってくると、お互いの特徴を覚えきれなくなります。そんな場合は身分証明書を提示して、相手を認証すると思います。
また、その身分証には顔写真がプリントしてあることも多く、結果としてWYAに依存するものも少なくありません。
- WHAT YOU KNOW (knowledge factor) パスワード、秘密の質問等、その人だけが知っていることを提示して認証をします。 コンピューターの世界でもっとも多く使われるファクターでしょう。
一般的に、上記3つのうちいずれか1つを満たすことで、認証が完了することが多いです。 しかし、より確実な認証を行いたい場合はMulti-Factor Authentication (MFA) という考え方で、複数のファクターを確認することもあります（2段階認証）
OpenID Connect
認証の の仕組み IDトークンという証明 書を利用して、本人確認済みであることを証明します。 (+ そのユーザーの属性（プロフィール）情報を知ることができます。)
OAuthと AuthOというのがあるらしい 認証プラットフォーム Auth0 とは
# 今後このユーザー認証周りをplantUMLで書く
ユーザ認証の基本フロー
参考URL(すばらしい) 一番分かりやすい OAuth の説明
ユビキタス
リソースサーバ : ユーザーのデータを管理するサーバ APIを守る仕組みのベストプラクティス : アクセストークン(あらかじめクライアントアプリケーションに渡す) アクセストークンを発行する係 : 認可サーバ ※認可サーバにアクセストークンをくださいといい、渡すまでの流れを標準化したものがOAuth 2.0 OAuthが明言していること : アクセストークンを発行する仕組みであって**認証については定められていない。**また、認証に必要な、ユーザー情報などの取得については決まっていない
基本的なユーザー認証のフロー
- クライアントからサーバに認証情報をおくる
- サーバー上で認証情報を検証する
- 認証情報が正しければ、クライアントにアクセストークンを送る(+必要に応じて セッションに記録する)
たとえばフォームにメールアドレスとパスワードを入力・送信し、入力内容が正しければサーバーからアクセストークン(これがAPIにアクセスできる認識だが？) が渡される、というイメージ
ユーザ認証を設計する上で決めるべきこと
| 順番 | 項目 | 選択肢 |
|---|---|---|
| 1 | 認証方法をどうするか | パスワード認証 or OpenID Connect(OAuth認証のこと「厳密には違うが」) |
| 2 | アクセストークンをどう管理するか | JWT |
| 3 | アクセストークンをどうStateに保持するか | Authorizationヘッダ, Cookieヘッダ |
| 4 | アクセストークンをどう保持するか | OS標準のストア?, メモリ, Cookie, localStorage |
1(認証方法をどうするかについて) 概要
まず、ユーザー認証の方法には、大きく次の2つがある。
| 認証方法 | 概要 | |
|---|---|---|
| 認証方法1 | パスワード認証 | IDとパスワードをサーバに送る |
| 認証方法2 | OpenID Connect | 外部のプロバイダ上で認証しアクセストークンをサーバに送る |
- 認証方法2について OpenID Connectは、OAuth認証と聞くとなじみがある。 たとえばGoogleやTwitterなどのアカウントによる認証。 ただ、『OAuth認証』という言葉には語弊がある。
パスワード認証とは
パスワード認証にも大きく分けて2つある
- Basic認証やDigest認証
- 独自の認証機構
※2の独自認証機構は例として、フォームからIDとパスワードをサーバに送って、ユーザ基盤をもとに認証を行う一般的なやり方。
この認証方法はパスワードを平文で送ることになるため、仮にSSLで通信を暗号化していたとしてもログにかかれて流出につながる
ユーザ基盤とは
ユーザー登録のあり方が時勢にそぐわなくなっている 以下のは時代遅れ
メールアドレスとパスワードを使用し登録をする。
なぜ？ 世のトレンドとしてEメール自体の利用シーンが減るに連れ、それを必須とするサービスまで使いづらいものになるという危機感がある。
2OpenID Connect(認証方法をどうするかについて)
OpenID Connectについて
OAuthがアクセストークンを発行する仕組みのみのため、認証については定められていない。 認証に必用なユーザー情報などの取得については決まっていない。
このOAuthを拡張し、ユーザー情報の取得についてなどを標準化したのがOpenID Connect
OpenID Connectは、『OAuth 2.0を使ってID連携をする際に、OAuth 2.0では標準化されていない機能で、かつID連携には共通して必要となる機能を標準化した』OAuth 2.0の拡張仕様のひとつである。
OpenID Connectによる認証のフロー
シングルサインオンを実現するためには様々な試みが行われている。そのひとつが認証方式の統一 Google認証やFacebook認証などSNSの認証を利用した認証方式が利用されている。 これらの認証方式はシングルサインオンに対応するための独自の認証規格に基づいている。
最近ではクラウドサービスの普及に伴って、これらの規格の利用が推進され、シングルサインオンが利用しやすくなっています。
用はアクセストークンをGoogle OAuthに取得しにいくフローのOpenID Connect版
- クライアントがプロバイダへIDトークンを要求する
- プロバイダがユーザー（クライアント）にIDトークンの発行可否を聞く。あわせて認証を行う
- ユーザー（クライアント）がプロバイダに発行可否と、発行する場合に認証情報を送る
- プロバイダがクライアントにIDトークンを発行する
この1と4のやりとりを標準化したのがOpenID Connectです。OAuthが『アクセストークンを発行する仕組み』なのに対して、**OpenID Connectはこれを拡張して『IDトークンを発行する仕組み』**と考えるとわかりやすいかもしれません。 『Googleなどのアカウント認証を使う』=『OpenID Connectを使う』という認識がもてればいいのかな、と思います。
Googleの認証方法はOpenID Connectではない OpenID Connectについて書きましたが、実際のところGoogleやTwitterの認証はOpenID Connectではありません。GoogleはOpenID Connectの仕様に準拠しつつ、OAuth 2.0を採用しています。TwitterはOAuth 1.0aという仕様で、OpenID Connectには準拠していません。
いずれにしてもOAuthをベースにした認証を行なっていますが、ここではわかりやすさのためにOpenID Connectという用語に統一して説明しています。