ユーザー アカウント、認証、パスワード管理に関する 13 のベスト プラクティス2021 年版 | Google Cloud 公式ブログ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本
認証と認可についての知識が必要になったので、基礎的なことを学んでいます。 一切何も知らない状態から手当たり次第に細かく調べるのは大変だったので、超サマリを整理してみようと思います。 この本は「個々の要素に詳しくなる必要はないんだけど、概要くらいはさっと把握しておきたい」とか「手当たり次第に詳細調査をする前に、一瞥してこれから踏み込もうとしている領域の超俯瞰マップを作る」という感じで使うことを想定しています。 同じ様な方の役に立ったら、とても嬉しいです。 この本は筆者の理解に連動して追記修正される可能性があります。
IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現
IPA のけしからん技術が再び壁を乗り越え、セキュアな LGWAN 地方自治体テレワークを迅速に実現 2020 年 11 月 3 日 (火) 独立行政法人情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室 登 大遊 独立行政法人 情報処理推進機構 (IPA) 産業サイバーセキュリティセンター サイバー技術研究室は、このたび、できるだけ多くの日本全国の地方自治体 (市町村・県等) の方々が、LGWAN を通じて、迅速に画面転送型テレワークを利用できるようにすることを目的に、J-LIS (地方公共団体情報システム機構) と共同で、新たに「自治体テレワークシステム for LGWAN」を開発・構築いたしました。 本システムは、すでに 8 万ユーザー以上の実績と極めて高い安定性 を有する NTT 東日本 - IPA 「シン・テレワークシステム」をもとに、LGWAN
マイクロサービスにおける認証と認可の、一般論としての設計パターンを調べたところ、Web 上の複数の記事で似たようなパターンが登場していた。ここでは、まず認証と認可が実現したい一般的な要件と、そのマイクロサービスでの難しさを整理し、認証と認可に分けて調査したパターンをまとめた。 あくまで “一般論” なので、実際には個々のドメインにあわせてアレンジが必要 往々にしてこの “アレンジ” に価値が宿るものだが、まずはセオリーを知っておきたいというモチベーションで調査した Web 上の記事を読んでまとめただけなので、手を動かしての確認はしておらず、理解が甘い部分はご容赦ください 具体的な通信方式やサービス間通信のセキュリティといった具体論までは踏み込めていない。このへんはサービスメッシュやゼロトラストネットワークといったトピックが登場すると思われる これらは次回以降の Todo としています その
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…
2023/10/05 Offersさんのイベントでの資料です。 https://offers.connpass.com/event/295782/ イベント後の満足度アンケート（5点満点）の結果は以下になります。 5点: 49% 4点: 39% 3点: 8% 2点: 4% こちらの…
本稿はJCB Advent Calendar 2024の12月14日の記事です。 3-Dセキュアにおける認証取引の仕組み解説 JCB デジタルソリューション開発部 アプリチームの村井です。 アプリチームではJCBが提供する様々なサービスの開発・運用をしています。 今回は非対面のクレジットカード決済で導入が進んでいる3-Dセキュア（本人認証サービス）について、 各システムの動きにフォーカスして認証取引の主な仕組みを紹介します。 3-Dセキュアの認証取引の仕組みは、提唱元であるEMVCoのサイトから公式ドキュメントをダウンロードできます。 本記事では公式ドキュメントの内容を噛み砕いて解説します。 そもそも3-Dセキュアって何？という方は過去の記事もご覧ください。 認証取引 認証取引の概要を図示します。 JCBではDSシステムを運用しています。 また、アクワイアラドメインで稼働するシステムが3D
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
はじめに こんにちは。株式会社Flatt Security セキュリティエンジニアの石川です。 本稿では、ログイン機能をもつWebアプリケーションにおける実装上の注意を、マイページ機能から派生する機能のセキュリティ観点から記載していきます。特に、XSS（Cross-Site Scripting）やSQLインジェクションのような典型的な脆弱性と比較して語られることの少ない「仕様の脆弱性」にフォーカスしていきます。 これから述べる実装上の注意点は、実際にはマイページ機能であるかどうかに関係なく注意するべきです。 しかし、開発者の視点に立つと「これこれの機能にはどのようなセキュリティ観点があるか」という形が読みやすく、また他の機能の仕様のセキュリティを考える上で想像力を働かせやすいものになるのではないでしょうか。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
少し早いですが、メリークリスマス！事業開発部の早川です。 早いもので、入社して 1 ヶ月半が経ちました。 現在は、 prismatix の理解を深めながら、導入支援を行っています。 今回はその中から、認証 / 認可についてお伝えします。 と言っても、これまでに同僚達が書いた分かりやすい記事がありますので、これらのガイダンスの形で、整理していきたいと思います。 ジョインしました 以来、初めての記事となりますﾄﾞｷﾄﾞｷ 目標 本記事をご覧いただいた後、こちらのスライドを何となく理解できる気がすることを目標とします。 本スライドに関するブログ記事はこちらです。 AWS Dev Day Tokyo 2018 で「マイクロサービス時代の認証と認可」の話をしてきた #AWSDevDay 目的 まず、認証 / 認可を学ぶ理由を考えてみました。 近年、様々なサービスが API を通じてつながり、より便利
iCARE Developer Meetupは、月次で開催している株式会社iCAREが主催するエンジニア向けのLT勉強会です。18回目の今回は、Ruby on Railsをテーマに行いました。サーバーサイドエンジニアの越川氏からはToken認証機能について。 Rails APIモードで開発するときの認証用のトークンはどこに保存すればいいの問題越川佳祐氏：私からは、「Rails APIモードにおけるToken認証機能について」というテーマでLT（ライトニングトーク）をしようと思っていたんですが、スライドを作っていて「あれ、これ別にRailsだけの話じゃなくない？」と思ってしまいました。みなさんの中にも、そう思う方がいるかもしれないんですが、もうこれで作っちゃったのでご了承ください。 私は株式会社iCAREで、サーバーサイドエンジニアをしている、越川と申します。Twitterは@kossy07
ritouです。 マシュマロでSPA+BE構成のWebアプリでOAuthやOIDCしたい！って話をよくいただきます。 最近だと、こんな質問がありました。 OIDCから発行されたトークンの取り扱いについて質問させてください。 SPA +OIDC(認可コードフロー)構成によるWEBアプリケーションの開発を考えています。 idPによる認証後、バックエンドとフロントエンドのAPI通信に使うべきはIDトークンとアクセストークンだとどちらになるのでしょうか？ 個人的には「ログイン成功した時点でOIDCの処理は終わり、あとかSPA + BEが独自のセッションCookieなりトークンを用いてよろしくやったら良いよ」という設計を適用します。もはや質... 続き→https://t.co/O2KWJrL4Mi#マシュマロを投げ合おう— 👹秋田の猫🐱 (@ritou) 2024年10月20日 SPAだろうが
はじめに 2023年4月に基盤エンジニアとして Ubie に入社しました nerocrux です。主に Ubie の ID 基盤の開発と保守運用を担当しています。 この記事は、2023 Ubie Engineers アドベントカレンダー 5 日目の記事となります。 Ubie では、モジュラモノリスを採用しつつ、マイクロサービスアーキテクチャも採用しており、領域によってサービスを分けて、それぞれの担当チームが開発と保守運用をしています。 クライアントから一つのリクエストを受け取ったあとに、Ubie のバックエンドではリクエストを受け取ったサービスだけがそのリクエストを処理することもあれば、別のサービスにディスパッチし、複数のサービスがひとつのリクエストを処理して結果を返すこともあります。 マイクロサービス間の通信が Ubie の内部で発生したとしても、必ずしも無制限で自由に行われていいわけで
はじめに 私は、手を動かしながらOAuth2/OIDC認可コードフローを学びたいと思い、この記事を書きました。本記事ではAmazon Cognitoを使ってOAuth2/OIDCの認可フローを学ぶハンズオンです。使用するのはCurlだけで、アプリケーションコードの準備は不要です。 目次 登場人物は4人 認可コードフローの概要 詳細な手順 セキュリティを向上させるために まとめ 登場人物は4人 1. クライアント(フロントエンド) Webアプリや、モバイルアプリなど、ユーザーの目に触れる画面を指します。今回は画面がないので、curlコマンドなどで代用します。 2. 認可エンドポイント(API) ユーザーの入力したIDやPasswordを検証し、認証が成功した場合に認可コードを発行します。この時点ではログインに成功していません。
前回の、社内プライベートポッドキャスト実現方法で、ポッドキャストサイトを静的配信しつつBasic認証をかけるというアイデアを書いた。しかし、Basic認証などなかなか使わなくなり、ネイティブでサポートしている静的ホスティングサービスも少ない。今回はCloudflare PagesのFunctions機能でリクエストをラップするミドルウェアを書けば実現できることが分かり、その方式を採用することにした。多少実装必要になるのと、認証周りを自前で書くのはあまりやりたくはないが、廉価に比較的省力で実現できるので受け入れる。 ネット上にいくつかサンプルは見つかるが、今回実装するにあたっては以下の点を留意した。 コード内に認証情報を載せない 複数ユーザーのIDとパスワードを管理できるようにする パスワードは定数時間比較してタイミング攻撃を防ぐ これらを以下のように解決することとした。 認証情報は環境変数
Passkey autofillを利用したパスワードレスログイン導入で得たものと、得られなかったもの - Money Forward Developers Blog
English version of this article is available here はじめに こんにちは、CTO室 IDサービス開発部のyamato(@8ma10s)です。 マネーフォワード IDという、当社サービス向けのIdPを開発しています。 今回このマネーフォワード IDにおいて、パスワードを使わずに、生体認証などを利用してログインできる「パスワードレスログイン」という機能をリリースしました。 また、今回のリリースでは、既にいくつかの他社サービスで導入されているような通常のパスワードレスログインUIではなく、「Passkey autofill」という、ブラウザの自動補完を利用する新しいタイプのパスワードレスログインUI を（恐らく日本のサービスで初めて。エンドユーザーの目に触れるサービスという意味では、おそらく世界でも初めて）導入しています。 私達がどういった過程で、
フルスクラッチして理解するOpenID Connect (1) 認可エンドポイント編 - エムスリーテックブログ
こんにちは。デジカルチームの末永(asmsuechan)です。 この記事では、OpenID Connect の ID Provider を標準ライブラリ縛りでフルスクラッチすることで OpenID Connect の仕様を理解することを目指します。実装言語は TypeScript です。 記事のボリュームを減らすため、OpenID Connect の全ての仕様を網羅した実装はせず、よく使われる一部の仕様のみをピックアップして実装します。この記事は全4回中の第1回となります。 なお、ここで実装する ID Provider は弊社内で使われているものではなく、筆者が趣味として作ったものです。ですので本番環境で使用されることを想定したものではありません。なんなら私は ID Provider を運用する仕事もしておりません。 1 OAuth 2.0 と OpenID Connect 1.1 用語の
Here I plan to share my technical knowledge and experience, as well as my interests in the subject. Please note that this tech blog is a space for sharing my personal views and ideas, and it does not represent the opinions of any company or organization I am affiliated with. The main purpose of this blog is to deepen my own technical skills and knowledge, to create an archive where I can record an
私が考えるマイクロサービスアーキテクチャ
はじめに 以前に、マイクロサービスアーキテクチャにゼロから挑んだ開発経験から、私が現時点で考えるマイクロサービスアーキテクチャを書いてみる。前回はAWSで構築したがAWSに限定せず汎用的に表現してみたいと思う。 前提 例として、社員の勤怠と有給の管理ができるようなwebのSaaSプロダクトを考える。 ここでいうプロダクトとは商品として販売できる最小の単位とする。 境界づけ まずは、プロダクトを5つの機能に分類する。 認証・・・認証を行うIdP。ユーザー固有のIDを管理するユーザーディレクティブを持つ。 ユーザー・・・認証されたユーザーと権限の紐付きを持つ。 権限・・・ロールとポリシーによる権限を設定する。「ユーザー」「権限」「勤怠」「有給」というサービスそれぞれに個別の設定ができる。 勤怠・・・勤務の開始と終了を管理できる。 有給・・・有給の付与、消化、残日数の管理ができる。 パターン1：
freee の権限管理基盤マイクロサービスの今を語ろう！ - freee Developers Hub
はじめに こんにちは、freee の 権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。前職ではできることをできる限りやろうというスタンスで開発チームをリードし、アーキテクチャ設計やチームビルディングなどに取り組んでいました。その後 2022 年に freee へ入社し、freee で初めてエンジニアリングマネージャーの役割に。変わらずできることにできる限り取り組むスタンスでチームビルディングに従事しています。 この記事では、我々のチームが担当している権限管理基盤について語っていこうと思います！ 権限管理基盤の成り立ち freee では、「スモールビジネスを、世界の主役に。」をミッションに掲げ、統合型経営プラットフォームの開発・提供を進めています。最近では freee Togo Panorama を公開するなど、統合に向け
freeeの礎となる認証認可基盤のマイクロサービス化プロジェクトの経緯と振り返り - freee Developers Hub
こんにちは、認証認可基盤・課金基盤のエンジニアリングマネージャーを務めている muraと申します。直近2年間は、今回お話しするfreeeの認証認可基盤のマイクロサービス化のプロジェクトにバックエンドエンジニア、エンジニアリングマネージャーとして携わってました。最近はfreeeが利用する課金基盤のエンジニアリングマネージャーも兼務するようになり、本格的にマネージャーの道を歩み始めたところになります。 本日は、私が2年間携わってきた「認証認可基盤のマイクロサービス化」のプロジェクトについてお話しします。このプロジェクトは私が入社するより前の2019年から進められてきたプロジェクトで、2022年6月末に移行に一区切りがついたものになります。プロジェクトの始まった経緯や実際の移行作業に加えて、4年間という長期間のプロジェクトへの振り返りについてお話させて頂ければと思います。 freeeの認証認可基
Passkey の動向 2023年ふりかえり - Money Forward Developers Blog
はじめに こんにちは、マネーフォワード ID 開発チームの @nov です。 2023年はマネーフォワード ID として本格的にパスキーのサポートを開始した年でした。 2023年4月にリリースしたマネーフォワード ID のパスキー実装ですが、2023年末の時点でマネーフォワード ID へのログインアクションの7%ほどがパスキーによるログインになっており、Google Sign-in や Sign in with Apple などを抜いてパスワードに次ぐ第二位の認証手段となっています。 この一年で、Money Forward Developers Blogにも、最初に Passkey Autofill に全面対応した実装でリリースに至った経緯や、定期的な利用状況レポートなどを挙げてきました。 Passkey autofillを利用したパスワードレスログイン導入で得たものと、得られなかったもの
マイナンバーカードを使いこなせ！ 確定申告に導入された新たな認証方式を学ぶ：半径300メートルのIT 確定申告時にマイナンバーカードとスマホを活用した新たな認証方式が導入されました。面倒な作業を簡略化してよりセキュリティを強化したこの仕組みを詳しく解説していきます。 確定申告のシーズンがきました。2022年は（特別な事情がなければ）3月15日までに申告を終わらせる必要があります。個人事業主は毎年「この苦行を何とかしなければ」と思っているのではないでしょうか。 この面倒な作業をデジタル化した仕組みが国税電子申告・納税システムの「e-Tax」です。e-Taxを使えば窓口に行かずWeb経由で所得税や消費税、贈与税の確定申告ができます2020年分の申告からは青色申告特別控除として65万円の控除を受けるにはe-Taxによる電子申告が必須となりました。「電子申告しなければ損をする」という状況ですので、
このアクション、ABAC ないし RBAC に対応してる？難解な IAM リファレンスに立ち向かうための地図を描いてみた | DevelopersIO
ここで、リソースタイプlistener（ CLB のリスナー）だけは、どのアクションからも「リソースレベルのアクセス許可」の対象とされていません。全てのリソースタイプで「リソースレベルのアクセス許可」に対応しているわけではないため、Elastic Load Balancing というサービスとしては黄色になっているというわけです。 おさらいとなりますが、このセルが緑の「あり」になっている AWS サービスにおいても、全てのアクションが「リソースレベルのアクセス許可」に対応しているわけではないという点に注意してください。 リソースベースのポリシー いわゆる IAM ポリシーを「アイデンティティベースのポリシー」と呼ぶのに対し、リソースに設定するポリシーはリソースベースのポリシーと呼ばれます。例えば S3 のバケットポリシーや、SNS のトピックポリシー、VPC エンドポイントのエンドポイント
GitHub - zitadel/zitadel: ZITADEL - Identity infrastructure, simplified for you.
Are you searching for a user management tool that is quickly set up like Auth0 and open source like Keycloak? Do you have a project that requires multi-tenant user management with self-service for your customers? Look no further — ZITADEL is the identity infrastructure, simplified for you. We provide you with a wide range of out-of-the-box features to accelerate your project, including: ✅ Multi-te
メールアドレスを持たないアカウントも freee 人事労務を利用できるようになりました - freee Developers Hub
はじめに こんにちは、freee で認証認可基盤の開発をしている okarin です。最近の休日は QR コードを実装して遊んでます。意外と仕組みが複雑で数学的にも難しいのですが、いろんな知識が身について楽しいのでオススメです。 先日、メールアドレスを持たないアカウントでも freee 人事労務というプロダクトを利用できるになりました。現在、freee 人事労務では、メールアドレスまたはログイン ID でのログインが可能となっています。本記事では、メールアドレスを持たないアカウントで freee 人事労務にログインする機能の開発の課題などをまとめました。 freee人事労務ログイン画面 課題 これまで freee ではメールアドレスを持たないアカウントでログインすることができませんでした。そうしたなかで、 freee 人事労務で勤怠を管理したいけれども、従業員に対するメールアドレスの発行は
AmplifyでCognitoのHosted UIを利用した認証を最低限の実装で動かしてみて動作を理解する | DevelopersIO
AmplifyとCognitoを利用すると、Amplifyがうまいことやってくれるので、プログラム開発者は認証フローを意識することなく認証機能が実装できます。 その、うまいことってのが具体的に何をやっているのかを暴きます。 Amplifyを使うと、Cognitoを利用して簡単に認証機能を作れて便利です。 詳しくは弊社ブログをご覧ください。 AWS Amplify+Angular6+Cognitoでログインページを作ってみる ~バックエンド編~ | Developers.IO AWS AmplifyとAngular8を使ってCognitoでAWS Management Consoleにログインするページを作ってみる | Developers.IO また、こういったログインのほかに、CognitoにはホストされたUIを利用してユーザー認証をするという機能があります。 イメージ動画を作成したので
セッションキャッシュによる SPOF（単一障害点）問題の解消 - freee Developers Hub
こんにちは、サービス基盤の横塚です。 freee のサービス基盤は、各チームがアプリケーション開発に専念できる環境を作ることをミッションに掲げるチームです。開発者の生産性を高めるような共通コンポーネントを整備したり、freee 全体が堅牢なシステムとなるような取り組みを日々続けています。 今回のテーマは、「認証サーバーの単一障害点問題を克服する」です。 freee の認証基盤 freee の中心にはログインするためのID情報や認証情報の管理を一手に引き受ける gRPC サーバーがあります。 freee の全アプリケーションはこの認証サーバーにアクセスしないと始まらないので非常に重要なコンポーネントです。もし認証サーバーがダウンしていたら、外からやってきたリクエストがどのユーザーからのものなのかさっぱりわからなくなってしまいます。当然アプリケーションは動かなくなるでしょう。 freee は会
JCB デジタルソリューション開発部 DXテックグループの村井です。 アプリチームではJCBが提供する様々なサービスの開発・運用をしています。 今回は非対面のクレジットカード決済で導入が進んでいる3Dセキュア（本人認証サービス）について、 その概要と3Dセキュアを構成するDSシステムの開発についてざっくりと紹介します。 3Dセキュアって何？ 3Dセキュアは、インターネットショッピング（非対面決済）でのクレジットカード決済における、本人認証（不正対策）サービスの仕様でありフレームワークです。 クレジットカードでネットショッピングを利用する際は通常、クレジットカードの「カード番号」「有効期限」「セキュリティコード」「氏名」といった、カードに記載された情報を入力すれば商品を購入できます。 しかし、上記の情報で商品を購入できるということは、悪意ある者にカードを盗まれて使われた場合、決済する人が正規
SSHの公開鍵認証とは何をやっているのか？
はじめに この記事は、SSHでのログインに公開鍵認証を使っているけど仕組みは知らないんだよな、という方に向けて書いたものです。 少し長いですが半分くらいは補足です。必要な部分だけ読んでいただければと思います。 公開鍵認証によるログイン手順 まずは公開鍵認証によるログイン手順を振り返っておきます。 クライアントで秘密鍵と公開鍵のペアを生成 公開鍵をサーバーに登録 SSH接続を試みる 初回であれば何か聞かれてよく分からないままyesを選択 ログイン成功 だいたいこんな感じではないでしょうか。なお、4はパスワード認証の場合でも聞かれますね。 公開鍵認証の仕組み 公開鍵認証には署名（デジタル署名）という技術が使われています。 まずは署名について説明し、次に署名を使ったユーザー認証について説明します。 署名 署名という技術には二種類の登場人物が存在します。署名者と検証者です。 署名者は、データに対し
デジタルアイデンティティのすべて
Phillip J. Windley 著、Drummond Reed 序文、富士榮 尚寛 監訳、柴田 健久、花井 杏夏、宮崎 貴暉、塚越 雄登、田島 太朗、名古屋 謙彦、村尾 進一、瀬在 翔太、松本 優大、安永 未来、池谷 亮平 訳 TOPICS 発行年月日 2024年12月 PRINT LENGTH 464 ISBN 978-4-8144-0098-0 原書 Learning Digital Identity FORMAT Print PDF 今日では、さまざまなサービスでソーシャルログインが当たり前になり、デジタルアイデンティティは多くの人に利用されています。デジタルアイデンティティは、ビジネスにおける信頼の構築と維持に欠かせないものですが、その全体像を正しく理解することは難しいものです。 本書は、デジタルアイデンティティとは何か、どのように機能しているのか、その基盤を提供するテクノロ
freee の二要素認証（ワンタイムパスワード）を仕組みから解説 - freee Developers Hub
はじめに こんにちは、freee で認証認可基盤の開発をしている okarin です。 freee のプロダクトでは二要素認証を有効にすると、メールアドレスとパスワードを入力した後、ワンタイムパスワードを求められるようになります。この二要素認証を利用することで、より安全に freee をご利用いただけるようになっています。本記事では二要素認証の仕組みを解説していきたいと思います。 ワンタイムパスワード入力画面 そもそも二要素認証とは？ 「記憶情報」、「所持情報」、「生体情報」のうち、2つを組み合わせる認証方式を二要素認証と呼んでいます。これらの2つ以上を組み合わせた認証方式を多要素認証と呼ぶこともあります。 freee では、「記憶情報」であるパスワードと、「所持情報」であるワンタイムパスワード（OTP）を利用して二要素認証を実現しています。 OTP の仕組み では、どうやって OTP を
The Copenhagen Book
The Copenhagen Book The Copenhagen Book provides a general guideline on implementing auth in web applications. It is free, open-source, and community-maintained. It may be opinionated or incomplete at times but we hope this fills a certain void in online resources. We recommend using this alongside the OWASP Cheat Sheet Series. If you have any suggestions or concerns, consider opening a new issue.
【図解】B2Bサービスに活用できるAuth0のOrganizations機能とは？ - TC3株式会社｜GIG INNOVATED.
はじめに B2B向けのサービスは法人や部署のように組織単位でサービスを提供し契約を締結してもらい、その組織単位でサービスを提供するということが必要になります。Auth0ではこういったB2B向けのサービスにも認証認可機能を容易に実装できるような便利機能としてOrganizationsという機能が提供されています。 本ブログ記事ではそのOrganizations機能のご紹介と、実際にB2B向けサービス提供時に求められる主な要件でどのように活用できるかをご紹介いたします。 Auth0のOrganizations機能とは？ まずはじめに、Auth0のOrganizations機能について簡単に説明します。冒頭で説明した通り、特にB2B向けのサービスを提供する場合に、サービスを組織メンバーとして認証認可させる必要がある際に使える便利な機能です。いわゆる1つのサービスをマルチテナント型に複数の組織（法
試したこと1 Next.jsを使っているので、Next.jsにより特化していそうな nextjs-auth0 から試してみる。 https://github.com/auth0/nextjs-auth0#getting-started をみながらAuth0側の設定を行う。 Application TypeにSingle Page ApplicationではなくRegular Web Applicationを選択するのがポイント。 ドキュメントどおりに進めると、ログイン機能ができた。 Cookieには多分SDK内部でセットされたappSessionという名前のセッションIDっぽいものがある。 LocalStorageは空でした。 試してみたこと2 nextjs-auth0 でのアクセストークンの取得。 サーバーサイドでのアクセストークンの取得 ドキュメントによると、getAccessToke
RBAC vs. ABAC：定義と使用方法 | Okta
大切なデジタル資産を守るには、アイデンティティ管理の手法を活用する必要があります。しかし、その保護はどのような形で行われるべきでしょうか。 ロールベースのアクセスコントロール（ロールベースのアクセス制御 / Role-Based Access Control / RBAC）と属性ベースのアクセスコントロール（属性ベースのアクセス制御 / Attribute-Based Access Control / ABAC）の違いを知ることで、スマートな意思決定が可能になります。 RBACとABACの主な違いは、アクセスを許可する方法です。RBACは、ロール別、つまり役割別にアクセスを許可する手法です。ABACは、ユーザーの属性、オブジェクトの属性、アクションタイプなどによってアクセスを決定する手法です。 以下に詳しく説明します。 ロールベースのアクセスコントロールとは？ RBACを使用する場合、
ソーシャルIDなどの外部IdPと連携をする際、外部IdP側がパスキーに対応している場合もあり、基本的にRP側はIdPの認証結果を信じて何もしないという文字通り「Relying」な感じで構成されることが多いと思います。
個人開発を何度もしてきて、何一つとしてリリースしてない私が考えてみました。 リリースしないというセキュリティ担保では、やはり駄目だろう、と。 駄目なんだろうな、と思い、自分なりに整理してみました。 個人的な結論 結論から話せ、と世の中がいうので結論から言います。 OIDCの処理はバックエンドで行えるならバックエンドで行う ブラウザから利用するWebシステムならCookieを使えば良い せっかくだしcookieにはJWTを入れておけばいい 個人的にはこんな感じでいいんじゃないかと思いました。 理由はここから先に記載します。興味があったら見てください。 セキュリティは難しいし、得意じゃないのでご指導ご鞭撻は優しくしてください。(祈り) OIDCの処理はどこに置くのがいいのか OIDC自体はブラウザで結果を受け取ることも、サーバで受け取ることも可能です。 ということは、まずそもそもどこで完結させ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microservices における認証と認可の設計パターン
30分でOpenID Connect完全に理解したと言えるようになる勉強会
仕様が読めるようになるOAuth2.0、OpenID Connect 入門
3-Dセキュアにおける認証取引の仕組み解説 - JCB Tech Blog
マイナンバーカードによるPDFへの電子署名がどのように動作するのかを実験してみた【イニシャルB】
Webサービスにおけるマイページの仕様とセキュリティ観点 - Flatt Security Blog
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
よりよくわかる認証と認可 | DevelopersIO
認証用トークン保存先の第4選択肢としての「Auth0」 | ログミーBusiness
SPA+Backend構成なWebアプリへのOIDC適用パターン - r-weblife
マイクロサービス間通信における認証認可およびアクセス制御
手を動かしながらOAuth2/OIDC認可フローを学ぶ（Cognito） - Qiita
Cloudflare PagesにそれなりにちゃんとBasic認証をかける | おそらくはそれさえも平凡な日々
Personal Tech Blog | hidekazu-konishi.com
マイナンバーカードを使いこなせ！ 確定申告に導入された新たな認証方式を学ぶ
3DセキュアにおけるDSの開発 - JCB Tech Blog
@auth0/nextjs-auth0 と @auth0/auth0-react の使い分け
外部IdP利用時にRP側"でも"多要素認証を行うべきか
OIDCを利用した個人的なWEBシステムで認証情報を何をもって維持するのか考えてみた
forums.funcom.com
mainichi.jp
www.asahi.com
ameblo.jp/uguisujyo777
ma-kko.com
plea5station.com