ritouです。 背景 これまで数年に渡り、「新規登録/ログイン時に登録状態がわかるレスポンスを返してくれるな。」というお話をしてきました。 SMSやEmailを入力して認証コードなどを送るタイプのログイン方法でも同様の実装は可能であり、表向きは「認証コードを送信したよ。受け取った値を入れてくれよな。」としつつ実際は既に登録済みだからログインからこい、未登録だから新規登録から来い見たいな内容を送りつつ、画面では正規のユーザーと同様のトークンなりを送り検証が絶対通らん！ みたいなのを実装したりしています。 ではこれをWebAuthnなりネイティブ機能で提供されるFIDO認証でこれを実現したいとなった時にどうしたら良いか、細かく考えたらやっぱりめんどいなって話をします。 想定する環境 パスワード認証と組み合わせる2FA用途ではなく、FIDO認証のみでログインさせる 最初にユーザー識別を行うかど

SPA認証トークンをどこに保存するかは論争が絶えません。localStorageやCookieがよく使われますが、Auth0は違う方法を採用しています。この記事では、Auth0のトークン管理の方式を理解でき、トークン管理上のセキュリティへの理解を深めることができます。 SPAの認証トークンをどこに保存するか ブラウザでトークンを保存できる場所 保存場所の比較 メリット・デメリット Auth0のアプローチ トークンはインメモリに保存 OpenID Connect準拠とトークン取得のUI/UXの悪化回避を両立 Auth0のjsライブラリ ログイン アクセストークンの（再）取得 図解 ログイン アクセストークンの（再）取得 自サービス内の認証だけのもっと簡易な構成 ログイン IDトークン取得 まとめ SPAの認証トークンをどこに保存するか React やVueで認証付きSPA（Single Pa

先日、RFC9116が発表されました🚀 あなたのWebサービスに潜在する未知の脆弱性を誰かが見つけた時、それをあなたに連絡する方法を提示するsecurity.txtを標準化するものです。 この記事では何故これが必要だったのか、そして私たちがこれを実装する方法を簡潔に説明します。 なぜこれが必要だったのか https://securitytxt.org/のSummary(概要)にはこのように書かれています。 Webサービスのセキュリティリスクが、リスクの重大性を理解している独立したセキュリティ研究者によって発見された場合、それらを適切に開示するためのチャンネルが不足していることがよくあります。 その結果、セキュリティの問題が報告されないままになる可能性があります。 security.txtは、組織がセキュリティ研究者がセキュリティの脆弱性を安全に開示するためのプロセスを定義するのに役立つ標

ここ1年ぐらい感じていた「学びに関する格差」の話を書く。 最初にまとめ・勝手に学ぶ人は、自分の周囲にある「学びに使えそうな仕事」を探して自分の仕事にすることを繰り返す ・期待されて学ぶ人は、上司とかの期待に応えて新しいことを学ぶ ・「勝手に学ぶ人のスピード」＞「期待されて学ぶ人のスピード」なので、格差が開いていく ・「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」が実現できない ・勝手に学ぶ人を止める理由も見つからない ・困ったなあ（解決策わからない） では詳細を書いていく。 勝手に学ぶ人：自分の周辺にある「誰も手をつけてない仕事」を発見し、自分の学びに利用するそれぞれが自分の担当範囲の仕事をしているとする。 それぞれが自分の担当範囲の仕事をしている勝手に学ぶ人は、「誰も手をつけてない」かつ「自分の学びになりそうな」仕事を自ら発見して、自分の仕事として取り組む。 勝手に学ぶ人

みなさま、こんにちは、こんばんはokzkと申します。 数年前にはAmebaの画像基盤でストレージを超ガンバッてた輩です。 今回は、内製の認証認可基盤のPERMANを紹介します。 PERMANって？ Permission Managerからとって、PERMANです。 (藤子不二雄先生の漫画とは一切関係ないです) 簡単にいうと認証/認可基盤ですが、難しい言葉でいうと、Identity Governance & Administration(IGA)に分類されるシステムです。 ユーザサービス向けではなく社内向けのサービスとなっています。 具体的にはRBAC(Role Base Access Control)を志向していて、なんか色々対応しています。 整理せずに、ざっと例を上げると以下のようなカンジです。 SAML2(AWS, Google, AzureAD, Slack, GitHub, その他

個人用メモです。 「git gcってあんまし容量減らないよなぁ」 と思ったのが動機です。調べたけどパッと腑に落ちる記事がなかったので「自分で git のソースコード見た方がいいな」と急にモチベ発動してグワっと勉強しました。またついでに歴史改変の方法も調べたのですが、公式で既に WARNING が出てるほど非推奨化されてるfilter-branchを使用してる記事が多かったので、2021 年現在で多分一番推奨されてるfilter-repoを使ってやる方法もまとめました。 ちなみに容量減らしても高速化するかというとそこまで単純ではないです。そもそも減らさなくても partial clone で blob オブジェクトを必要最低限に指定して昔の blob をデフォルトで持ってこないようにしたり(--no-checkoutと併用するとより効果有る)、その後本当に自分が必要なやつだけ sparse-

普段使うサービスで、会社用のアカウントとプライベートのアカウントを分けると便利でセキュアですよね？うっかり間違って仕事のデータを大公開してしまうリスクも小さくなります ただ、日本国内では、アカウント分離はNGで、個人ごとに1つのアカウントに集約しないと規約違反であるという言説が広まっているようです。 認識共有用に頑張って書いた図。指摘歓迎ですそこでGitHub Supportに事実を確認したところ(英語)、規約違反ということはないという話でした。会社側で有償のオーガニゼーションを契約し、仕事用アカウントを所属させていれば、各自のプライベートアカウントは無料でOKです。 ロジックとしては、オーガニゼーションに所属させているアカウントは有償コーポレートアカウント(名称仮)なので、個人アカウントに対する無料アカウントの複数所持禁止条項は無関係となります。 該当条項 One person or l

こんにちは、BASEのフロントエンドチームでエンジニアリングマネージャーをやっている松原(@simezi9)です。 私は最近ではマネージャーとしてコードを書くことよりもチームの編成や採用などをメインに業務を行っているのですが、 そんな中でチラっと書いたコードで見事に落とし穴にハマって失敗をしたのでその共有記事です まえがき BASEのフロントエンドチームは現在15名ほど（うち業務委託5名）で運営されています。 この人数は今後もどんどん増えていく予定なのですが、目下全社的にリモートワークになっている事情も手伝ってメンバー同士の関係性が希薄になってしまう懸念を持っていました。 BASEの中では常に複数のプロジェクトが走っているのですが、それぞれのプロジェクトにフロントエンドエンジニアは2〜3名ずつ配置されています。 そんななかでアサインされた人同士がフロントエンドエンジニア同士であるにも関わら

この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任

こんばんは。ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 1日めの記事です。 qiita.com 初日なのでゆるふわな話をしましょう。 何の話か もうだいぶ前ですね。9月のお話です。こんなTweetを見かけました。 社内Slackにいる「OAuth認証」と書くと訂正してくれるbotが丁寧な解説をするようになっていた 認証(Authentication)と認可(Authorization)は間違えやすいわりにミスると甚大な被害をもたらしがちなので、常日頃から意識を高めていきたいですね pic.twitter.com/oVQxBgZcHS— greenspa (@greenspa) 2020年9月28日 このbotに対する思うところはもう良いです。 今回は、「OAuthの仕様に沿ってID連携を実装するいわゆる"OAut

Go 言語はシングルバイナリをウリにしたプログラミング言語です。バイナリファイルを1つポンと scp で転送すれば動くのでとても便利です。シングルバイナリとなると当然、画像や HTML といったアセットをバイナリに埋め込みたくなります。 Go 言語ではこれまで go-assets や go-bindata、statik というツールを使う事でファイルのコンテンツをバイナリ化し、変数からアクセスする様にしてきました。 しかしそれらには色々な流儀や OS 間でのまばらな動作など、ユーザにとって納得のいかない物がありました。昨日、Go 言語ではオフィシャルとしてこのファイル埋め込みをサポートする様になりました。Go 1.16 から使える様になります。 cmd/go: add //go:embed support · golang/go@25d28ec · GitHub +3 −3 src/cmd

社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意ください。 Twitter: @DddEndow

2020年5月末でP&Gのブランドマネージャーを退職しました。僕はこのNOTEで、P&Gで非言語的に受け継がれているマーケティングの思考法を、分かりやすい教科書のようにまとめようと思います。本気で読めば1時間かからず読めると思います。が、ちゃんと理解すれば知識レベルとしては本何冊分にもなることをお約束します。さらには、そのマーケティング思考の先に、僕がどんなマーケティングの進化を考えていて、そのために次のチャレンジとしてどんなアクションを取ろうと思っているかも最終章にまとめようと思っています。 総合商社から中途採用でP&Gのマーケティング本部に採用され、シンガポールのアジア本社への異動も伴いながら、世界最高峰のブランドマネジメントの"いろは"に触れらたことは、本当に幸運なことです。直近では、ファブリーズのブランドマネージャーとして、ブランドレコードとなる売り上げを達成することが出来たのは、

実際の暗号システムがセキュアに動作し続けるためには、暗号アルゴリズム自体がセキュアであるだけでは不十分で、データが保護される期間中、その暗号アルゴリズムが使用する暗号鍵もセキュアに管理されている必要があります。そのため、暗号鍵やデータのライフサイクルを踏まえた運用、安全な暗号鍵の保管、暗号鍵危殆化時の対策などを行う上で参考となるガイドラインを取りまとめています。 「暗号鍵管理システム設計指針（基本編）」の内容 「暗号鍵管理システム設計指針（基本編）」は、あらゆる分野・あらゆる領域の全ての暗号鍵管理システムを対象に、暗号鍵管理を安全に行うための構築・運用・役割・責任等に関する対応方針として考慮すべき事項を網羅的に提供し、設計時に考慮すべきトピックス及び設計書等に明示的に記載する要求事項を取りまとめたガイドラインとして作成されたものです。 具体的には、暗号鍵管理の必要性を認識してもらうために「

今月、とうとうオンプレミス環境がその役割を終えたので、当たり障りのない範囲で思ひでを記録しておこうと思います。 だいたい 2002年 から運用が始まったので18年ほどの歴史でしたが、血と汗と…… 血と汗くらいですかね滲んでるのは。さぁ振り返りです。 大阪 私が参画した時にはインフラエンジニアというかサーバー担当者が既に１名おり、「サーバーやってみない？楽しいよ！」と言われて乾いた笑顔を返したのを覚えています。 当時は京都の極小ベンチャー企業で、なぜ最初が大阪のデータセンターだったのかは聞きませんでしたが、とある現地作業についていって、ハーフラック１台に１Ｕ２台が積載されていました。このへんは私自身かなりのペーペーだったので知識不足もあり記憶がかなり曖昧です。 平々凡々に運用していたある日、WEBサイトへのアクセスが途絶えました。 社長の「ねぇ、サイトに繋がらないんだけど」の一言が口火です。

2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきましたRead less

fun <T : Comparable<T>> List<T>.quickSort(): List<T> = when { size < 2 -> this else -> { val pivot = first() val (smaller, greater) = drop(1).partition { it <= pivot } smaller.quickSort() + pivot + greater.quickSort() } } fun main() { print(listOf(5, 0, 1, 5, 3, 7, 4, 2).quickSort()) }