サマリ
- google oauthを使って得られたアクセストークンはあくまで google apiを叩くためにある
- 外部認証を使うことで自社に id providerなどを置かずにすむというわけではない
はじめに
私は元々、セキュリティに関する関心はそれほど高くありませんでした。自分にとって最も重要なのは、価値ある機能を迅速に提供することだったためです。
しかし、昨今のKadokawaをはじめとするITにおけるクリティカルな問題の発生を目の当たりにして、自分の知識をアップデートする必要性を感じ、今回この記事を書くことにしました。
手始めに、OAuth2.0を使ったサービスの作り方についてまとめました。（最近のランサムウェアの問題とは直接関係ありませんが）
OAuthを使った認証/認可の仕組みは、現在ではインターネット上で調べてコピペしたり、Amazon Cognitoなどを使うことで、仕組みや動作の流れを詳しく知らなくても簡単に実装できてしまうほど普及しています。しかし、もしその仕組みに誤りがあったらどうなるでしょうか？その疑問からフローについて復習し、再確認しました。
ここではGoogleを認証サーバーとして使用する場合を想定していますが、適宜プロバイダーを読み替えてください。
フロー
今回伝えたいのは特に Accessing Company Resources の部分です。
他の部分についてはいくらでもわかりやすい記事があるので簡単に記述します。
認証と認可の基礎
OAuth2.0は、認証と認可を安全に実現するための標準プロトコルです。認証とは、ユーザーが誰であるかを確認するプロセスであり、認可とは、特定のリソースへのアクセス権限を付与するプロセスです。
認証: ユーザーのアイデンティティを確認します。例えば、Googleログインを使用してユーザーがGoogleアカウントの所有者であることを確認します。
認可: 認証されたユーザーに特定のリソースへのアクセス権を与えます。例えば、Googleカレンダーのイベントを読み取る権限を付与します。
Google OAuthの役割
Google OAuthは、ユーザーがGoogleアカウントを使用してサードパーティのアプリケーションにアクセスを許可するためのメカニズムを提供します。これにより、ユーザーは アプリケーションに対して自分のGoogleデータへのアクセスを安全に許可できます。
この部分に全てが詰まっていて、別にGoogle OAuthはサードパーティアプリのために認証認可をしてあげるよ。と言っているわけではなく、サードパーティからGoogle APIへのアクセスができるようにするよ。と言っているだけです。
会社リソースへのアクセス
Google OAuthを使って得られたアクセストークンを、会社リソースへのアクセスに使用する場合、追加の検証が必要です。これは、Googleのアクセストークンがそのまま会社のリソースに対して有効であるわけではないためです。会社は独自のIDプロバイダーを使って、アクセストークンの有効性を確認し、必要な権限をチェックします。
つまり、認証にGoogle OAuthを使って、認可の仕組みは自分たちで用意することが望ましいと考えています。
※ 正確にいうとGoogle OAuthを使って得られたアクセストークンを工夫して使って、アクセス制御を行うことは可能ですが個人的にいいものと思っていないので、やり方などは言及はしません
まとめ
Googleで認証
→ 自社のid providerにユーザーを作成
→ id providerでアクセストークンを発行するなり、アクセス権限をユーザーに返す
→ 自社リソースへのアクセス
基本的にはこんな流れになるかと。
これらを理解していれば、Amazon Cognitoに何を設定すればいいのか、Google OAuthの設定に何を入れればいいのか、サーバー側でどのような処理を行う必要があるのか。などやればわかるようになると思います。
最後に本当に大事だと思ったので、繰り返しになりますが
あくまでGoogleなどがOAuth認証を提供しているのは、サードパーティーアプリからGoogleのAPIを実行するため
上記のように個人的には理解しています。
信頼できる認証機能が備わっている結果として、自社でパスワード持たなくていいなど色々メリットはありますが本質的には上記の文章を押さえておく必要があると思いました。