cognito
#aws #認証 #idaas
切り取り線.icon
調査、作業ログ
IDaaSとシングルサインオンの関係を理解しよう|IDaaS推進室|Okta - IDaaS - クラウド型ID管理・統合認証サービス:株式会社日立ソリューションズ
「1つのパスワードを使えばすべてのシステムやサービスにログインできる仕組み」が必要とされるようになった結果、生まれたのが「シングルサインオン」という仕組みです。
AWS再入門ブログリレー2022 Amazon Cognito編 | DevelopersIO
ID・パスワードを入力する必要があるシステムやサービスは社内に数多くあり、システムごとにパスワードを管理することは非常に手間がかかります。
Amazon Cognitoとは、ウェブアプリケーションやモバイルアプリケーションに「認証(Authentication)」、「認可(Authorization)」、「ユーザー管理」を簡単に実装することが可能なサービスです。
これはまあ直感的にわかるよなonigiri.w2.icon
クラウドサービス利用が増えるに伴いID・パスワード管理が煩雑になってきているのです。
そのような課題を解決するサービスが「IDaaS」です。
ん??つまるところなんだろ、シングルサインイン(SSO)を実現するための仕組みがIDaaS(IDentity as a Service)てことかもonigiri.w2.icon
「IDaaSで実現するシングルサインオン」とは「クラウドサービスとオンプレミス環境のシステムの認証情報をSaaSで一元管理する」ということになります。
ホイホイ、理解理解onigiri.w2.icon
なんかクライアント視点で語られてるよなぁ...IDaaSの説明ってonigiri.w2.icon
Webサービス開発者が認証の仕組みをアウトソースする視点で語られてるの欲しいな
しかしIDaaSを活用すれば、異なる認証基盤をスムーズに統合することが可能です。それぞれの組織で利用しているActive Directoryなどの認証基盤をIDaaSに連携することができます。
M&Aやグループ化、グローバル展開などによって組織の増減が発生したとしても、IDaaSであれば各組織の認証基盤をスムーズに統合することが可能です。
ここも、なんか従業員のパスワード管理的な視点よな。toCにおけるユーザーの認証管理っていう視点で語れてるものが欲しいonigiri.w2.icon
IDaaSはどこからでもアクセスできるクラウドサービスであり、インターネット上にあること自体がメリットの1つです。
ホイホイ。このポイントを1つ抑えておこうonigiri.w2.icon
toCユーザーに対してIDaaSを使う際も、ユーザー情報をクラウド上で管理するってわけやな
IDaaSのデメリット
1. 1つパスワードが漏れるだけで数多くの社内システムにアクセスできてしまう
2. シングルサインオンシステムの障害発生
3. すべてのシステムをシングルサインオンにできない可能性
「1.」に関しては、指紋認証などの多段階認証で対処可能っぽい
「2.」はだるいな。冗長化進めないと。
「3.」はうん、はい。
IDaaSとは何か? Azure ADやOktaなどのクラウド型ID管理サービスを比較する |ビジネス+IT
IDaaS(Identity as a Service)とは、クラウド上のさまざまなサービスのID管理を一元的に行うクラウドサービスだ。利用者は、IDaaSに1回ログインするだけで、事前に登録・連携しているクラウドサービスはすべて使えるようになる。
Webサービス開発者としては以下のようなイメージで使うのだろうかonigiri.w2.icon
IDaaSにユーザーをログインさせる。
そのログイン情報を元に、自分のサービスにもログインさせる的な。
IDaaSの役割は、「ゼロトラストネットワーク」を構築することだ。ゼロトラストネットワーク(ZTN)とは、リソースを利用しようとするすべてのトラフィックに対し、「毎回認証することで脅威を防ぐ」というネットワークの概念である。
ゼロトラストネットワークってそんな感じなんやonigiri.w2.icon
IDaasで実現するのねぇ
IDaaSの主な機能
1.認証機能
2.ID管理
3.ID連携
4.認可
5.監査
基本的に自分が今一番求めてるのは「1.」かなonigiri.w2.icon
Auth0 + Cognito IDプールで認証基盤を構築! | Ragate ブログ
AWSの認証基盤といえば、Cognito です。Cognito にはユーザープールと ID プールという種類があります。前者はユーザーを管理および認証し(認証)、後者は認証されたユーザーの情報をもとに権限を与えます(認可)。
q.icon ユーザープールとIDプールの役割の違いを再確認しようonigiri.w2.icon
a.icon
ユーザープール:
ユーザーの認証を管理するやつ
IDプール:
ユーザーのIDを作成して、そのIDに対してAWSの操作権限を一時的に与えるやつ
【セキュリティ】AWS Cognito/Google Identity/Azure AD B2C/Auth0結局の認証サービス(IDaaS/IAM)はどう言った基準で採用すれば良いのかまとめてみました。 – Self branding
Auth0はAWS上で動いている故、上乗せになっている分価格面では少し他に比べ高めです。(TwilioもAWS上にあり同じ立場)
専門サービスというだけあり、アカウント連携の豊富さや認証周りの準拠数は圧倒的なので、その辺りが採用の是非を決めるかと考えられます。
Auth0がやはり、この界隈では一番機能が豊富っぽいなonigiri.w2.icon
その分コストも高めに出ると...なるほどなるほど
【AWS】AWS Amplify&Cognitoで認証・認可で「車輪の再発明」はやめてセキュリティ要件を一気にクリアしつつモダンなアプリ開発する方法を解説します。 – Self branding
実装手段ではAWS Amplifyを用いたCognitoを利用したアプリケーションの開発の流れを紹介したいと思います。
ちょくちょくAmplifyが出てきよるな。こいつは一体何者だonigiri.w2.icon
Amazon Cognito User Pool(ユーザープール)とAmazon Cognito Identity Pool(IDプール)の組み合わせの流れを確認
①ユーザープールへサインイン、ユーザープールトークンを取得
②IDプールでユーザープールトークンとIDプールトークンを交換
③AWS各種サービスにIDプールトークン付きのリクエストでアクセス
理解。まずはユーザープールへのサインインが必要なのねonigiri.w2.icon
ていうかWebサービスの認証機能実装くらいなら、このユーザープールだけで事足りるのでは?
q.icon Cognitoで認証機能を作る場合、ユーザプールだけでOK?
a.icon
Firebase Authentication, Auth0, Amazon Cognitoを比較した - Qiita
今では様々なプロダクトが、認証の処理は他のサービスに任せる傾向にあると認識しております。そもそもセキュリティの分野は奥が深い(自身もほとんど理解できていない)ですし、プロダクトの成長にフォーカスしたいのに、セキュリティの分野に時間を割くのは悪手でしょう。
そやんなonigiri.w2.icon
最近はこの傾向が強くなってるんかなるほど
調べてみると想像より多くのサービスが存在することがわかりました。
Amazon Cognito, AWS Amplify Authentication, Auth0, Firebase Authentivation, ...
ここら辺が主要な認証管理サービスにはなってきそうやなonigiri.w2.icon
Amazon Cognitoの特徴
50000人まで無料
以降は1人あたり0.0055USD
高度なセキュリティ機能利用だと一人あたり0.050USD追加
50,000人かぁ〜〜〜onigiri.w2.icon
でもちょうどいいな。ユーザ数少なめのアプリとかやったらちょうどいい。
パスワード忘れに対する実装は自前でやる必要ありそう
Firebase Authenticationの特徴
無料(Sparkプラン) 電話認証が月1万回まで
有料(Blazeプラン) 電話認証が従量課金
電話認証とかいらんのだが?SMS認証のことかなonigiri.w2.icon
普通のパスワード認証とかはどうなってる?
Auth0の特徴
プランによって様々
無料でも利用可能
ref: https://auth0.com/jp/pricing
もう、自分で調べないとちゃんと比較できんなonigiri.w2.icon
Userfront core JS library
この資料いいね。Firebaseが見た目的に良さそうな気はした。
FastAPI と AWS Cognito を使用した JWT 認証 | アマゾンス・ゴントラム | | | | | 中くらい