タグ

認証と設計に関するlocke-009のブックマーク (5)

  • マツコの知らない LINE ログインの世界

    Ubie プロダクトプラットフォーム所属の nerocrux です。今回は Ubie において、 LINE ログインを成功させるために工夫したことをいくつか紹介したいと思います。 面白いこともすごいこともやってないし、対象読者もよくわかりませんが、興味があったら読んでみてください。 はじめに 症状検索エンジン「ユビー」について Ubie では、症状検索エンジン「ユビー」(以下、ユビーと呼ぶ)という一般ユーザー向けのサービスを展開しています。ユーザーが簡単な質問を回答することで、関連する病名や、適切な受診先情報を得ることができるサービスとなっています。 ユビーは Web ブラウザ経由で利用されることが多いですが、iOS / Android のネイティブアプリも提供しています。 ユーザーがユビーを利用する際に、ユビーのアカウントを作成することで、一貫性のある問診・受診・受診後のフォローアップ体

    マツコの知らない LINE ログインの世界
  • セキュアなAWS環境の設計についての解説【2024年版】 - サーバーワークスエンジニアブログ

    こんにちは!イーゴリです。 AWS にとって、クラウドのセキュリティは最優先事項です。(AWS公式ページ) AWS環境のセキュリティ対策としてAWSサービスを解説するよりも、まずはAWS環境の最適な設計について考える必要があります。AWS Well-Architected Frameworkを考慮しながらの設計を推奨します。AWS Well-Architected Frameworkを全部詳しく読むことをおすすめしますが、この記事では個人的に一番重要だと思う点について記載します。 とてもざっくり説明しますと、AWS Well-Architected Frameworkとは、クラウドシステムの最適な設計方法を提供するAWSのガイドラインで、6つの柱があります。この記事では基的に「セキュリティ」の柱を技術的観点から見てみたいと思います。 AWS Well-Architected Framew

    セキュアなAWS環境の設計についての解説【2024年版】 - サーバーワークスエンジニアブログ
  • なぜソーシャルログインの際にemailをキーにして参照するのか

    ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023 の 初日の記事です。 こちら、参加者を募集中です!気軽に参加してみてください!してくれよ!はよ! なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ

    なぜソーシャルログインの際にemailをキーにして参照するのか
  • APIトークン認証の論理設計

    SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です(しかもデフォルトでは有効期限なし)。 有効かどう

    APIトークン認証の論理設計
  • Auth0で脆弱なWebアプリケーションを作る~設計編~ - Qiita

    はじめに 今から1つ大きな脆弱なポイントがあるアプリケーション(フィクション)の設計を紹介します。どこに問題があるか考えながら読んでみいただけると楽しめるかもしれません。 事業会社のCIOとベンダー企業のある話。 注 : この話はフィクションです CIO: 「ウチのECサイトにAuth0を導入しようと思う」 ベンダー: 「Auth0ですか、最近Oktaに買収されたIDaaSですよね」 CIO: 「そーそー、これを機にセキュリティリスクを転嫁してしまった方がええんやと思う。ということで認証システムのリプレースよろしく」 ベンダー: 「はい!!!」 数ヶ月後 ベンダー: できました! CIO: 「おー、じゃあテキトーにシーケンス図でも見せて」 ベンダー: 「はい、ではまずログインのところから。現在SPAで構築されているWebアプリケーションを認可コードフロー+PKCEで認証しトークンを取得しま

    Auth0で脆弱なWebアプリケーションを作る~設計編~ - Qiita
  • 1