はじめに

現在個人開発を友人と作ってます。

自分はバックエンドをメインで担当することになったのですが、

最初にぶち当たったのが認証をどうするかということ。

色々やってみようと思います。

ちなみに、構成はメチャクチャです。

メモ形式で書いていくと思います。

多分最後には自分なりの結論に落ち着くと思うので、一緒に考えるつもりで読むとストレスないかと思います。

まずそもそも

Railsにはgemというどこぞの誰かが作った便利プログラムがあって、

その便利プログラムの中に認証系では有名な deviseがあります。

apiモードであれば合わせて devise-jwtとかdevise-token-authとかですね。

最初はそれを使おうとしました。

使い慣れていたし。

ただ問題があります。

カスタマイズが大変。
いろんな処理がブラックボックスになりがち。特にwardenとか。コード追うのだけでも一苦労。
メッセージをいじるのも大変。
google認証とかと合わせるのがだるい(とよくきく)

とこんな感じです。

ということで今回は自作しようと思います。

さてさて

自作するということですが、そもそもどのようなことを管理する必要があって

どのようなことに気をつければ良いのでしょうか。

ただemailとpasswordだけもらってdbに検索かけて一致すれば ok、みたいな

サンプルアプリ丸出しレベルなのも気が引けるのでここは今後の勉強も兼ねて

少し深く考えてみようと思います(AIと一緒に)

まずどんな情報が必要か。

Userは作る予定なので、name, profile, avatar_url, backgroud_urlとかあればいいですかね。

email含めるか含めないかですが、今後google認証とか考えた時に

認証情報をuserテーブルに加えると肥大化するとの指摘をAIちゃんから受けたので

別テーブルに切り出そうと思います。

providersテーブルとでもしましょうか。

userとhas_manyな関係を持つもので。

providerのtypeにemailとかgoogleとか入れられるとして。

あとは何かいるかな。

情報の識別子みたいなやつに何を採用するのかな。

emailかな。

Rails+omniauth-google-oauth2でGoogleログイン(devise無し)

というかそもそもSNS認証ってなんだ。

ソーシャルログイン（SNS認証）とは？概要やメリット・デメリット、実装するための方法まで徹底解説！ | 株式会社G-gen（旧株式会社トップゲート）

一般的なSNS認証においては、アプリケーションの相互接続性を維持するために「 OpenID Connect 」と「 OAuth 2.0 」の 2 つの通信規格

よく聞く2つだ。

一番分かりやすい OpenID Connect の説明 #OAuth - Qiita

一番分かりやすい OAuth の説明 #OAuth - Qiita

読んだ感じをまとめると、SNS認証とは

あるアプリケーションにログインする際に認証情報としてユーザが所有しているSNSアカウントの認証情報を使用すること。

だと思う。

でそのSNS認証をする上でルールがあり、それがOAuth2.0及びOpenId Connectというものと理解した。

でさらにOpenId Connectは OAuth2.0の拡張版だということも理解した。

違うのかな。

OAuthの目的は SSOに近いのかな。

一回認証すれば他のアプリにもシームレスに移動できる？

接続できるの方が正しいか。

ユーザの代わりにあるアプリで管理している情報へのアクセス権を問い合わせてきたアプリケーションに対して付与するというのが目的？

認証はお前が誰であるかを、認可はあるuserに対してある対象への権限を許可すること

OAuthとOpenID Connectについて～仕組みや特徴など解説～ – ユーザー認証・認可のかもめエンジニアリング

OAuthは認可を行う、OpenIDConnectは認証を行うためのプロトコルらしい。

oauthは「クライアントに対して、リソースサーバへの操作権限を付与する」

認可サーバ、アクセストークンのやり取りをあるルールに落とし込んだもの

認可にアクセストークンを使用する

トークンにはjwtを利用するんだって。

jwtって何

基本から理解するJWTとJWT認証の仕組み | 豆蔵デベロッパーサイト

JSON WEB Tokenの略。

いろんな情報をJSONにまとめた後に、1つの文字列としてコンパクトにまとめたもの。

そのJSONにおけるkey : valueのペアをクレームというらしい。

あとJWTはあくまでデータをまとめるためのものであり、認証とは一切関係ない。

誰かが「あ、これ認証に使えんじゃね」ということで JWT認証という言葉が出てきたらしいが

本来は認証のために作られたものではないらしい。

あとJWTは誰かに漏れたらデコードしてすぐに中身が見えるらしい。

それに状態を持たないのでステートレスということでもある。

それじゃ困ったということで、JWSという仕組みが導入されたらしい

JWSはJSON Web Signature。

header.payload.signatureらしい。

ちなみにjwtというのはpayloadのこと

header.payloadを指定した暗号化方式で暗号化したあと、渡した秘密鍵で署名したものがsignatureになるっぽい。

でこのJWSをよくあるサイトでは、リクエストヘッダにAuthorization: Bearer JWSのトークンをセットして

ガチャガチャやるっぽい。

ただ気づいたけど。

これなりすまし簡単では？

調べたところ、改ざんは検知できると思う。

よほどのことがない限り。

改ざんてどういうことをするかというと例えばpayloadに含ませる情報に知らない人の識別情報とすり替えるとか。

それは最終的にdecodeする際に秘密鍵と指定の暗号化方式で複合して突合する段階で弾けると思う。

問題は、そのtokenを使って誰かがなりすましとして入ろうとする時。

どうやって防御壁を作るんだろう。

【Rails】APIモードかつクロスオリジン間でCookieやSessionを使う方法【SPA】 #Ruby - Qiita

わからんな。迷走しそうだからこれまでにしとこう。また次の機会に。

参考文献(特に参考になったもの)

JWTとJWSについて