CADDiプロダクト横断の認証認可基盤を開発している話 - CADDi Tech Blog
注意! 2023年8月時点の内容となりますので、参考情報としてご覧ください。現在、アーキテクチャを見直し、同等の機能をより効率的に実現できる構成にして随時開発中です。機会が来たら新しいアーキテクチャの構成を紹介します CADDi Platformグループの前多です。 私たちはCADDiのプロダクト横断の技術課題を解消するための活動をしています。 これまでの活動の詳細は 信頼性を高めるサービス基盤と技術選定を見てください。 これまでの活動はクラウドインフラや開発環境の整備などが大半でしたが、今後のCADDiのプロダクト開発を発展させるために、プロダクト共通で必要となるサービス基盤の開発にも着手しています。 現在私たちが開発しているのは、CADDiプロダクト全体で利用する想定の認証認可基盤です。 認証認可に関する製品は、Auth0などのSaaSをはじめ、他にもさまざまな製品があります。 私たち
「使える人にだけ使わせる」 ~ マネーフォワード IDのログインUXから見るパスキー普及のポイント - r-weblife
ritouです。 いよいよドコモさんもパスキー対応が始まりましたね！いや、これを書いている時点ではまだです。 k-tai.watch.impress.co.jp それよりも、今回はマネーフォワード IDのパスキー対応に注目します。 corp.moneyforward.com (4/5追記) マネーフォワード側からも解説記事が出ていました。この記事で言いたいことが全部書いてあります。 moneyforward-dev.jp ブラウザのパスワードマネージャー機能を利用したパスワード認証のUX パスキー対応に触れる前に、マネーフォワードIDのパスワード認証のUXから見ていきましょう。 マネーフォワードの「メールアドレスでログイン」のフローを何も考えずに使うと、最初にメールアドレスを入れてからパスワード入力を求めるUXになっています。 このようなUXでブラウザのパスワードマネージャーの機能を使う場
Goを使ってGCPのサービス間認証をする
はじめに Cloud Run便利ですよね。コンテナをデプロイするだけで勝手にスケールしてくれますし使わない時はゼロインスタンスに出来ますし。こうした取り回しの便利さに加えて「良いな」と個人的に機能の一つがアカウントレベルのアクセスコントロールです。 Authenticationを「未認証を許可」にすれば公開APIとして誰でも使える状態になりますし、ACLの設定をすればサービスアカウントやユーザアカウント単位で実行できるユーザやアプリを限定出来ます。こういったセキュリティをアプリ側で作りこまなくて良いのは楽ですよね。 今回ちょっとIdentity Tokenをどう取り出すのか？ でハマってので「どのように認証をするのか」「IDトークンをどのように取得するのか」をメモがてら書いていきたいと思います。 なお、前半は結果として不要だった調査の話なので結論だけ知りたい人は後半へGo。 TL;DR A
GCP からの HTTP リクエストをセキュアに認証する
はじめにGCP にはあらかじめ HTTP のエンドポイントを登録しておくと、そこに対して HTTP リクエストが送られてくるようなプロダクトがいくつか存在します。 Cloud Pub/SubCloud TasksCloud Schedulerどれも非同期系の処理を行うプロダクトであり、非同期処理を行う Worker を HTTP の Web サーバとして記述できるのが大きなメリットになっています。 しかしそれらの Web サーバはパプリックなエンドポイントとして用意することも多いことから、送られてきた HTTP リクエストが本当に GCP の特定のプロダクトから送られてきたものなのか？という「認証」をどうやるかが長らく問題になっていました。 既存のやり方としては Web サーバの実装方式によっていくつかありますが、 App Engine (1st gen) を使う場合: “login: a
GCP の Application Default Credentials を使った認証 - ぽ靴な缶
公式ドキュメントで説明されているけど、同僚に何度か説明する機会があったり、作る必要のないサービスアカウントキーを目にすることも多いのでまとめておく。 認証情報が登場しないアプリケーションコード 例えば以下のコードで Secret Manager に保存したトークンを取得することができる。SecretManagerServiceClient にサービスアカウントキーを渡さずとも動作する。 const {SecretManagerServiceClient} = require('@google-cloud/secret-manager'); const client = new SecretManagerServiceClient(); (async () => { const [secret] = await client.accessSecretVersion({ name: 'proj
GCP の Compute Metadata Credentials について
Google Cloud Platform(以降 GCP) の認証認可については GCP と OAuth2 などの記事があるが、 Compute Metadata credential そのものの解説はあまり十分にされているとは言えないので、今回一つの記事で説明する。 Compute Metadata Credentials と聞いてもピンと来ない人向けに書くと、「Cloud Run や Cloud Functions などの GCP のプロダクトから GCP の API を呼ぶのにサービスアカウントキーが必要ないこと」の裏側がどのように動いているかの話について説明する記事である。 Compute Metadata Credentials とは Compute Metadata Credentials は Google Cloud Platform(以降 GCP) の標準の credent
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
