SNS認証について

# SNS認証について
- 学習マッチングサイトを作成して、google認証を実装したい
- 認証機能について理解を深めたい
## 環境
- AWS：EC2,RDS(MySQL),VPC,Route53
- webサーバー：NGINX
- アプリケーションサーバー：Puma
- フレームワーク：Ruby on Rails

## 認証の仕組みについて
今回はgoogle認証であるため、登場人物は、

- googleのリソースサーバ
- エンドユーザー
- webアプリ
- googleの認可サーバー

です。
### リソースサーバーとは
リソースサーバとは、保護対象のリソースを保持しているサーバーを指します。ここでいうリソースとは、googleフォトの画像やプロフィール情報等のことと思います。
### ユーザー
リソースオーナであり、アカウントを連携したいユーザーを指す。
### webアプリ
これは、つまり、学習マッチングサイトです。
### 認可サーバー
リソースサーバーに信頼されたサーバーで、リソースオーナーの認証を行い、リソースサーバーに対するアクセストークンを発行します。これが、OAuthの根幹となるサーバーです。OAuth2.0は、アクセストークンの要求とその応答を標準化したものであり、マニュアルのようなものではないかと思います。
## 　認証フロー
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1923339/7a823001-cbdb-a835-7cd6-0492998e444a.png)
①ユーザーが「Googleでログインする」ボタンをクリックする。
②認可サーバーに認可リクエストを投げる。
③webアプリが認可画面をユーザーに表示する。
④ユーザーがアプリの認可リクエストを承認する。
⑤webアプリがその旨を認可サーバーに伝える。
⑥認可サーバーがwebアプリに認可コードを発行して、webアプリが認可コードを提示することで、アクセストークンを取得する。
⑦webアプリがアクセストークンを提示して、リソースサーバからリソースを取得する。

という感じでしょうか。他にもフローが存在するので、間違っていたらご指摘お願いします。
[一番分かりやすい OAuth の説明](https://qiita.com/TakahikoKawasaki/items/e37caf50776e00e733be)
[OAuth 2.0 全フローの図解と動画](http://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f)
[OAuth2.0の流れをまとめてみる](https://zenn.dev/mryhryki/articles/2020-12-28-oauth2-flow)
## 作業フロー
手順は以下を想定していました。

①GoogleCloudPlatformの設定を行う。
②取得したクライアントIDとクライアントシークレットをwebアプリに登録して、認可サーバーへ認可リクエストを投げる準備をする。
③取得したユーザー情報(今回は名前とメールアドレスとパスワード)を使ってユーザー情報を作成・保存し（customersテーブルに保存）、deviseで認証を行うことで、ログインを実現するように、実装する。

ちなみに、deviseの認証は、「該当のユーザー情報がどのモデルのどのレコードかを確認することである」ことが分かりました。deviseは登録されたパスワードを暗号化したり、様々な認証機能が備わっているため、何やら難しい感じがしますが、根本は意外と単純なことをしていると分かりました。
[Deviseのモヤモヤを解消して快適なRailsライフを送ろう！](https://zenn.dev/kitabatake/articles/start-to-like-the-devise)

## HTTPSとHTTP
上記①から③まで行なった後に、google認証のためには、HTTPSの必要があることが判明しました、、、
そもそも、HTTPやHTTPSとは、WebサーバーとWebブラウザの間で、Web情報をやりとりするためのプロトコル（通信規則）
です。これは通信を安全に行うための仕組みです。両者の違いは、暗号化されているかいないかです。HTTPSが暗号化されています。
暗号化されることによるメリットは、ネットバンキング、クレジットカード決済サービス、個人情報登録や編集を行うようなケースで有効です。HTTPのリクエストやレスポンスが暗号化されることにより、インターネットのどこかで誰かが盗聴しても、その内容を知ることは出来ません。また、通信中に誰かが通信内容を改ざんしたことを検知することも可能で、接続先のWebサーバーが本物かを検証する機能もあります。
これらのメリットから、SEO的観点で良しとされています。HTTPS通信が可能でなければgoogle認証を実装できない点もその根拠であると言えると思いわれます。また、これはfacebook認証にも同じことが言えます。そして、HTTPSは外部との通信を行う際には必須と言っていいかと思われます。

[HTTPとは？HTTPSとの違いをサイト移行で実施する
リダイレクト設定などをもとに解説](https://www.itmanage.co.jp/column/about-http-https/)
## SLL化
HTTPSによる暗号化通信はSSLサーバー証明書をサーバーにインストールすることで実現できます。暗号化通信はSSLサーバー証明書に表示されたサーバの所有者であることを証明し、ブラウザとサーバー間でSSL暗号化通信を実現します。
## ドメインについて
SSL化するためには、ドメインの取得が必要です。そして、ドメインの取得にも、複数の手続きが必要となります。
登場人物は、
- DNS（Domain Name System）
- フルサービスリゾルバ
- ネームサーバー
- ELB（Elastic Load Balancing）
### DNSとは
ドメイン名とIPアドレスを紐づけるシステムです。人間がわかりやすいように、IPアドレス（数値の羅列）をドメイン名（文字の羅列）に変換します。このシステムを担当するのがDNSサーバーで、「フルサービスリゾルバ」と「ネームサーバー」の2種がある。
### フルサービスリゾルバとは
ドメイン情報を教えて欲しいという問い合わせをネームサーバーにするサーバーです。問い合わせ結果を一定期間保存することで、再度同じ名前で問い合わせがあった時に高速化し、ネームサーバ負荷の軽減を図ることができます。この保存時間をTTL(Time To Live)と呼ぶ。
### ネームサーバーとは
ドメインとIPアドレスを紐づける台帳（ゾーンファイル）を持ったサーバーです。フルサービスリゾルバからのドメイン情報を教えて欲しいという問い合わせに対して、返答します。
### ELBとは
他のサービスへのトラフィックを、仮想サーバーなどの複数のターゲットに自動的に分散して、安定稼働をサポートするAWSのサービスです。複数のサーバーへの負荷を均一化して、障害への耐性を高めます。

ちなみに色々あってネームサーバを一度変更したのですが、うまく変更できていなかったようで、DNSのレコードにあるTTLを確認すると７２時間とあったのですが、反映されずに７２時間を経過しました。スマートフォンからはアクセスできたのですが、作業していたPCからは、パブリックipもドメインでもアクセス不可の状態でした。原因も分からなかったため、EC2インスタンスを削除して、作り直しました。
[【サーバー移管】DNS変更と反映を速くする方法を徹底解説！](https://unicorn-blog.jp/archives/12546#:~:text=%E5%8F%8D%E6%98%A0%EF%BC%88%E6%B5%B8%E9%80%8F%EF%BC%89%E3%81%BE%E3%81%A7%E3%81%AE%E3%82%BF%E3%82%A4%E3%83%9F%E3%83%B3%E3%82%B0,%E3%82%8B%E3%81%93%E3%81%A8%E3%81%8C%E5%A4%9A%E3%81%84%E3%81%A7%E3%81%99%E3%80%82)
[なんで私のドメイン名のDNSはちゃんと機能していないの?? [DNS基本確認事項5つ]](https://news.gandi.net/ja/2021/06/why-isnt-my-dns-working/)
[独学向けRailsアプリをAWSにデプロイする方法まとめ【入門】](https://qiita.com/gyu_outputs/items/b123ef229842d857ff39)

## AWSのサービス達
### Route53
ドメインの取得とネームサーバーの設置を行いました。AWSの提供するDNSサーバーであると思います。
[【初心者向け】AWSでドメイン名を取得する方法！Route53使用](https://hiyowa-na-engineer.com/aws-get-domain/#i-4)
### Certificate Manager
SSL証明書を発行するのに利用したサービスです。
### ELB
上記に登場しましたが、これはユーザーからのアクセスに対してはHTTPSでやり取りを行い、EC２に対してはHTTPでやり取りを行うための仲介役であるイメージかと思います。また、これにSSL証明書を登録して、HTTPS通信を実現します。
## HTTPSによるアクセスフロー
①ユーザーがドメイン名を使って（「https://」から始まるURL）アクセスしてくる。
②ELBがリクエストを受け取る。つまり、リスナーがHTTPS通信でリッスンするということと思います。
③ELBがEC2とHTTP通信でやり取りして、webサーバーやアプリケーションサーバー、webアプリ（Rails）が動いてレスポンスを返す。つまり、HTTPSでリッスンした後に、targetに対してHTTPで通信しするということと思います。
④ELBがレスポンスを受け取り、ユーザーにHTTPSで情報を提供する。
ざっくりとこんな感じでしょうか？

[AWS + お名前.com でSSL化してみた](https://qiita.com/toshi_machine/items/b3fc8bd25cfca040bf31)
[AWSでSSL化する方法を伝授！！！](https://qiita.com/nakanishi03/items/3a514026acc7abe25977)
[SSL化したサイトにアクセスすると502 Bad Gatewayと出る](https://teratail.com/questions/292930)
## Google認証
割愛します。以下を参照しました。
以下２つはしっかりとした理解に役に立ちました。
[公式　OmniAuth: Overview](https://github.com/heartcombo/devise/wiki/OmniAuth:-Overview)
[【Rails】omniauth_callbacks_controllerについて](https://qiita.com/yoshi_4/items/580374b30242a265ec22)
以下３つはざっくりとした理解に役に立ちました。
[[Rails] Facebook/Twitter/Googleでのユーザー登録をDevise & Omniauthを使って爆速で実装する](https://qiita.com/kazuooooo/items/47e7d426cbb33355590e)
[Rails googleを使ったSNS認証](https://qiita.com/akioneway94/items/35641ad30c2acb23b562)
[【Rails】SNS認証の登録手順(Twitter、Facebook、google)](https://qiita.com/manbolila/items/8caa1f5d2b1fb96d2646)
[DeviseとOmniauthでtwitter,facebook ログイン機能](https://qiita.com/sakakinn/items/321e6b49c92b9f02f83f)
## まとめ
ネームサーバーを変更したことで、３日以上の空白が空いてしまい、かなりモヤモヤしていましたが、そこそこスッキリしました。webアプリへの実装は比較的容易でしたが、AWSの設定にかなり苦労しました。502エラーにもぶち当たりました。ただし、これがあったからこそ、Railsというフレームワークでなんとなくできるgoogle認証機能ではなくて、インフラからOAuthまでの基本的な部分も学んだ上での機能実装となったので、色々と学べて、少しAWSが好きになったので、よかったです。何かご指摘あれば教えていただけると助かります。