パル、認証をどのように実装しますか？

アプリケーションの標準ユーザー認証については誰もが知っています。 これは昔ながらの登録手順です。ユーザーはメールアドレスやパスワードなどを入力し、入り口でメールやパスワードを保存されたデータと比較します。 一致する場合、アクセスを許可します。 しかし、時代は変わり、他の多くの認証方法が今日登場しました。 万華鏡のようなソフトウェア開発の世界のように、この変化において人気のプログラマー/開発者であり続けたい場合は、これらすべての新しい方法について知っておく必要があります。

どのアプリケーションおよびOSでも、「認証」がユーザーデータの安全性を確保し、情報へのアクセスを規制する上で非常に重要な要素であることは否定できません。 どの認証方法が最適であるかを理解するには、すべての方法の長所と短所を理解し、それらがどのように機能するかをよく理解する必要があります。

ここでは、今日最も一般的な認証方法についてお話します。 これは詳細な技術ガイドではなく、それらを紹介する方法にすぎません。 メソッドはWeb上のアプリケーションを考慮して説明されていますが、これらのアイデアは他の条件でも実装できます。

Web /インターネットのほとんどがHTTPプロトコルで構築されていることを既に知っていると仮定します。 また、Webアプリケーションがどのように機能するか、アプリケーションでのユーザー認証の意味、およびクライアント/サーバーアーキテクチャとは何かを知る必要もあります。

準備はいい？ 行こう

セッションベースの認証

HTTPプロトコルは状態を監視せず 、ユーザー名とパスワードでユーザーを認証する場合、アプリケーションはこれが前のリクエストのように本人かどうかを知りません。 再度認証する必要があります。 HTTPはすべてのリクエストで、以前に何が起こったかについて何も知りません。リクエストを送信するだけです。 したがって、個人データが必要な場合は、アプリケーションが自分であることを認識できるように、再度ログインする必要があります。 非常に迷惑かもしれません。

この不便さを取り除くために、ステートフルトラッキングを実装したセッション/ Cookieに基づく認証を考え出しました。 つまり、認証レコードまたはセッションはサーバーとクライアントの両方に保存する必要があります。 サーバーはデータベースまたはメモリ内のアクティブなセッションを追跡する必要があり、セッションIDが保存されているフロントエンドでCookieが作成されます。 これはCookieベースの認証であり、最も一般的で広く知られている方法で、長い間使用されています。

セッションベースの認証手順：

1. ユーザーがブラウザに名前とパスワードを入力すると、クライアントアプリケーションがサーバーにリクエストを送信します。
2. サーバーはユーザーを確認し、認証し、一意のユーザートークンをアプリケーションに送信します（メモリまたはデータベースに保存します）。
3. クライアントアプリケーションは、トークンをCookieに保存し、以降の各リクエストでトークンを送信します。
4. サーバーは、認証を必要とする各要求を受け取り、トークンでユーザーを認証し、要求されたデータをクライアントアプリケーションに返します。
5. ユーザーが終了すると、クライアントアプリケーションはトークンを削除するため、このクライアントからの以降のすべての要求は認証されなくなります。

この方法にはいくつかの欠点があります。

• ユーザー認証ごとに、サーバーは自身のレコードを作成する必要があります。 通常、これはメモリに保存され、多数のユーザーがいると、サーバーの負荷が高すぎる可能性があります。
• セッションはメモリに保存されるため、スケーリングはそれほど簡単ではありません。 サーバーを繰り返し複製する場合、すべてのユーザーセッションをすべての新しいサーバーに複製する必要があります。 これはスケーリングを複雑にします。 （セッションを管理する専用サーバーがあればこれは回避できると思いましたが、これは実装が難しく、常に可能であるとは限りません。）

トークンベースの認証

トークンベースの認証は、シングルページアプリケーション、Web API、モノのインターネットの急増により、近年非常に人気が高まっています。 ほとんどの場合、 Json Web Token（JWT）はトークンとして使用されます。 実装は異なりますが、JWTトークンは事実上の標準になりました。

トークンに基づく認証の場合、 状態は監視されません 。 サーバーやセッションにはユーザー情報を保存しません。また、クライアントに使用されるJWTも保存しません。

トークンベースの認証手順：

1. ユーザーはユーザー名とパスワードを入力します。
2. サーバーはそれらをチェックし、user_id、パーミッションなどのメタデータを含む可能性のあるトークン（JWT）を返します。
3. トークンはクライアント側に保存されます。ほとんどの場合、ローカルストレージに保存されますが、セッションストレージまたはCookieに保存することもできます。
4. 通常、後続のサーバーリクエストには、このトークンがBearer {JWT}の形式で追加の認証ヘッダーとして含まれます。 別のトークンは、POST要求の本文で、さらに要求パラメーターとして送信できます。
5. サーバーはJWTを復号化し、トークンが正しい場合、サーバーは要求を処理します。
6. ユーザーがログアウトすると、クライアント側のトークンは破棄され、サーバーと対話する必要はありません。

より詳細な説明 。

この方法にはいくつかの利点があります。

• 主な利点：メソッドは状態を使用して動作しないため、サーバーはユーザートークンまたはセッションを含むレコードを保存する必要がありません。 各トークンは自己完結型であり、検証に必要なすべてのデータを含み、要求されたユーザー情報も転送します。 したがって、トークンによってスケーリングが複雑になることはありません。
• Cookieには、ユーザーセッションIDを保存するだけで、JWTでは、有効なJSONであれば任意のタイプのメタデータを保存できます。
• Cookieを使用する場合、バックエンドは従来のSQLデータベースまたは代替のNoSQLを使用して検索を実行する必要があり、データ交換はおそらくトークンの解読よりも長く続きます。 さらに、ユーザー権限などの追加データをJWT内に保存できるため、データを受信および処理するための追加の呼び出しと検索クエリを保存できます。
  
  アプリケーションによって作成された最後の注文を返すAPIリソース/ api /注文があるが、それらを表示できるのは管理カテゴリのユーザーのみだとします。 Cookieを使用してからリクエストを行う場合、セッションを検証するためのデータベースへの1回の呼び出し、ユーザーデータを取得してユーザーが管理者のメンバーであるかどうかを確認するための別の呼び出し、およびデータを取得するための3回目の呼び出しを生成します。
  
  また、JWTを使用する場合、カスタムカテゴリを既にトークンに保存できます。 サーバーが要求して復号化すると、データベースを1回呼び出して必要な注文を取得できます。
• モバイルプラットフォームでCookieを使用するには、多くの制限と機能があります。 また、トークンはiOSおよびAndroidでの実装がはるかに簡単です。 さらに、Cookieは、Cookieのストレージが提供されていないモノのインターネットのアプリケーションおよびサービスに実装するのが簡単です。

これらすべてのおかげで、トークンベースの認証が今日人気を集めています。

パスワードレス認証

「パスワードなしの認証」という用語に対する最初の反応は、「パスワードなしで誰かを認証するにはどうすればよいですか？」 これは可能ですか？」

パスワードは私たちのアカウントの絶対的な保護源であるという信念は、私たちの頭の中に埋め込まれています。 しかし、問題をより深く研究すると、パスワードレス認証は安全であるだけでなく、名前とパスワードによる従来のログインよりも安全であることがわかります。 パスワードが古くなっていると聞いたことがあるかもしれません。

パスワードレス認証は、ログイン手順を構成し、パスワードを入力せずにユーザーを認証する方法です。 アイデアはこれです：

メール/ユーザー名とパスワードを入力する代わりに、ユーザーは自分のメールのみを入力します。 アプリケーションはこのアドレスへのワンタイムリンクを送信し、ユーザーはそれをクリックして、サイト/アプリケーションを自動的に入力します。 パスワードなしの認証では、アプリケーションは、他人のアドレスではなく自分で書いた場合、リンク付きの手紙がメールボックスに届いたと見なします。

SMSによる1回限りのリンクの代わりに、コードまたは1回限りのパスワードが送信される同様の方法があります。 ただし、アプリケーションをtwilioなどのSMSサービスと組み合わせる必要があります（このサービスは無料ではありません）。 コードまたはワンタイムパスワードもメールで送信できます。

そして、もう少し（これまでのところ）人気のない（そしてAppleデバイスでのみ利用可能な）パスワードレス認証方法：指紋認証にTouch IDを使用します。 テクノロジーの詳細 。

Slackを使用する場合は、パスワードなしの認証がすでに発生している可能性があります。

Mediumは、メールでのみサイトへのアクセスを提供します 。 最近、 Auth0またはFacebook AccountKitが 、アプリケーションにパスワードレスシステムを実装するための優れたオプションであることを発見しました 。

何がおかしいのでしょうか？

誰かがユーザーのメールにアクセスできれば、アプリケーションやサイトにアクセスできます。 ただし、ユーザーのメールアカウントのセキュリティについて心配するのは頭痛ではありません。 さらに、誰かが他の誰かのメールにアクセスすると、パスワード回復機能を使用して、パスワードレス認証でアプリケーションのアカウントを傍受することができます。 しかし、ユーザーのメールに対しては何もできません。 続けましょう。

利点は何ですか？

「パスワードを忘れた」リンクを使用して、サイト/アプリケーションへの入力に何度か失敗した後に思い出せないいまいましいパスワードをリセットする頻度はどれくらいですか？ 私たちは皆この状況にいます。 特にセキュリティを気にして各サイトに個別のパスワードを作成する場合は、すべてのパスワードを覚えていません（これらすべてを「少なくとも8文字で構成し、少なくとも1つの数字、小文字、特殊文字を含む」必要があります）。 パスワードレス認証は、これらすべてからあなたを救います。 あなたは今、「私はパスワードマネージャーを使っています、ばか」と考えています。 尊敬する しかし、大多数のユーザーはあなたのような技術者ではないことを忘れないでください。 これを考慮する必要があります。

パスワードレス認証は、ユーザーだけでなく、開発者としてのあなたにも適しています。 パスワード回復メカニズムを実装する必要はありません。 みんなが勝ちます。

一部のユーザーが昔ながらのユーザー名/パスワードを好むと思われる場合は、両方のオプションを指定して選択できるようにします。

パスワードレス認証は、今日急速に人気を集めています。

シングルサインオン（SSO）

Gmailなどの一部のGoogleサービスでブラウザにログインし、Youtubeや別のGoogleサービスにアクセスするときに、そこにログインする必要があることに気づきましたか？ 会社のすべてのサービスに自動的にアクセスできます。 印象的でしょ？ 結局のところ、GmailとYoutubeはGoogleのサービスですが、まだ別々の製品です。 1回のログイン後、すべての製品でユーザーをどのように認証しますか？

この方法は、シングルサインオン（SSO）と呼ばれます。

さまざまな方法で実装できます。 たとえば、中央サービスを使用して、複数のクライアント間でシングルサインオンを調整します。 Googleの場合、このサービスはGoogleアカウントと呼ばれます 。 ユーザーがログインすると、GoogleアカウントはCookieを作成します。Cookieは、ユーザーが会社が所有するサービスにアクセスしたときに保存されます。 仕組み：

1. ユーザーは、Googleサービスのいずれかのメンバーです。
2. ユーザーは、Googleアカウントで生成されたCookieを受け取ります。
3. ユーザーは別のGoogleサービスにアクセスします。
4. ユーザーは再びGoogleアカウントにリダイレクトされます。
5. Googleアカウントは、ユーザーに既にCookieが割り当てられていることを確認し、ユーザーを要求された製品にリダイレクトします。

単一のエントリポイントの非常に簡単な説明：ユーザーは1回ログインすると、各システムにログインすることなくすべてのシステムにアクセスできます。 この手順では、友人を直接的および間接的に信頼する3つのエンティティを使用します。 ユーザーは、IDプロバイダー（IDP）からパスワードを入力（または別の方法で認証）して、サービスプロバイダー（SP）にアクセスします。ユーザーはIDPを信頼し、SPはIDPを信頼します。

非常に単純に見えますが、特定の実装は非常に複雑になる可能性があります。 この認証方法の詳細をご覧ください。

ソーシャル認証

この写真は誰もが知っていると確信しています。

これは、しばしばソーシャルサインインまたはソーシャルログインと呼ばれます。 ソーシャルネットワーク上のアカウントでユーザーを認証できます。 そうすれば、ユーザーはアプリケーションに個別に登録する必要はありません。

正式には、ソーシャルログインは個別の認証方法ではありません。 これは、アプリケーションへのユーザーの登録/入力プロセスを簡素化する単一のエントリポイントのバリエーションです。

2つの世界のベスト

ユーザーは、ソーシャルネットワークのいずれかにアカウントを持っている場合、ワンクリックでアプリケーションを入力できます。 ユーザー名とパスワードを覚える必要はありません。 これにより、アプリケーションの使用体験が大幅に向上します。 開発者としてのあなたは、ユーザーデータのセキュリティについて心配する必要はなく、メールアドレスのチェックについて考える必要もありません-それらはすでにソーシャルネットワークによってチェックされています。 さらに、ソーシャルネットワークには既にパスワード回復メカニズムがあります。

使い方

開発者は、この認証方法の仕組みを理解する必要があります。 ほとんどのソーシャルネットワークは、認証メカニズムとしてOAuth2を介した認証を使用します（TwitterなどのOAuth1を使用するものもあります）。 OAuthとは何かを見てみましょう。 ソーシャルネットワークはリソースサーバーであり、アプリケーションはクライアントであり、アプリケーションを入力しようとするユーザーはリソースの所有者です 。 リソースは、ユーザープロファイル/認証情報です。 ユーザーがアプリケーションにログインしたい場合、ユーザーを認証のためにソーシャルネットワークにリダイレクトします（通常、これはソーシャルネットワークURLを含むポップアップウィンドウです）。 認証に成功したら、ユーザーはソーシャルネットワークから自分のプロファイルにアクセスするための許可をアプリケーションに与える必要があります。 その後、ソーシャルネットワークはユーザーをアプリケーションに戻しますが、アクセストークンを使用します。 次回、アプリケーションはこのトークンを取得し、ソーシャルネットワークのユーザープロファイルから情報を要求します。 これがOAuthの仕組みです（簡単にするため、技術的な詳細は省略しました）。

このようなメカニズムを実装するには、アプリケーションをさまざまなソーシャルネットワークに登録する必要があります。 ソーシャルネットワークへの接続を構成するためのapp_idおよびその他のキーが提供されます。 また、手順を簡素化し、不必要な手間を省くのに役立ついくつかの一般的なライブラリ/パッケージ（ Passport 、 Laravel Socialiteなど）があります。

二要素認証（2FA）

2要素認証（2FA）は、ユーザーのIDを検証するために2つの方法（要素とも呼ばれます）を使用することにより、アクセスのセキュリティを向上させます。 これは、 多要素認証の形式です。 おそらく発生しなかったかもしれませんが、ATMでは2要素認証が行われます。正しい情報を銀行カードに記入し、さらにPINを入力する必要があります。 誰かがあなたのカードを盗んだ場合、コードがなければ彼はそれを使用できません。 （事実ではありません！-注。Per。）つまり、2要素認証システムでは、ユーザーはいくつかの個別の情報を提供した後にのみアクセスを取得します。

もう1つのよく知られた例は、Mail.Ru、Google、Facebookなどの2要素認証です。このログイン方法が有効になっている場合、最初にユーザー名とパスワードを入力し、次にSMS経由で送信されるワンタイムパスワード（検証コード）を入力する必要があります。 通常のパスワードが侵害された場合、アカウントは保護されたままになります。これは、ログインの2番目のステップで、攻撃者が必要な確認コードを入力できないためです。

ワンタイムパスワードの代わりに、指紋または網膜画像を2番目の要素として使用できます。

2要素認証では、ユーザーは3つのうち2つを提供する必要があります。

• 知っていること：パスワードまたはPIN。
• 持っているもの：物理デバイス（スマートフォン）またはワンタイムパスワードを生成するアプリケーション。
• あなたの一部：指紋、声、網膜画像などの生物学的にユニークな特性。

ほとんどのハッカーは、パスワードとPINコードを探します。 トークンジェネレーターまたは生物学的特性にアクセスするのははるかに難しいため、今日では2要素が高いセキュリティアカウントを保証します。

つまり、これは普遍的な解決策ですか？ おそらく ない 。

それでも、2要素はアプリケーションの認証セキュリティを強化するのに役立ちます。 実装方法 たぶんあなたは自転車に乗るべきではありませんが、 Auth0やDuoなどの既存のソリューションを使用してください。

認証または承認？

一部の人々は、認証と承認という用語を混同しています。 これらは異なるものです。

• 認証は、身元の確認です。 名前とパスワードを使用してアプリケーションを入力すると、認証されます。
• 承認は、何かにアクセスできるかどうかのチェックです。 これは、一部のアクションに対する一連の権限である場合があります。 たとえば、アプリケーションでリソースを作成した場合、このリソースを削除できるのはあなただけであり（所有者であるため）、他のユーザーはそのために「許可」されません。

もっとここに？

おめでとうございます、あなたは長く退屈で退屈な記事を首尾よく読みました。