こんばんは。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
はじめに X.509 証明書について解説します。(English version is here → "Illustrated X.509 Certificate") ※ この記事は 2020 年 7 月 1 日にオンラインで開催された Authlete 社主催の『OAuth/OIDC 勉強会【クライアント認証編】』の一部を文書化したものです。勉強会の動画は公開しており、X.509 証明書については『#4 X.509 証明書（１）』と『#5 X.509 証明書（２）』で解説しているので、動画解説のほうがお好みであればそちらをご参照ください。 1. デジタル署名（前提知識） この記事を読んでいただくにあたり、デジタル署名に関する知識が必要となります。つまり、「秘密鍵を用いて生成された署名を公開鍵で検証することにより」、「対象データが改竄されていないこと」や「秘密鍵の保持者が確かに署名したこと
セキュリティエンジニアが本気でオススメする開発者向けコンテンツ 20選 - Flatt Security Blog
画像出典: 書籍...記事中に掲載した販売ページ / Webサイト...スクリーンショット はじめに こんにちは。株式会社Flatt Securityの @toyojuni です。 突然ですが、弊社Flatt Securityは「開発者に寄り添ったセキュリティ」を標榜しています。Webアプリケーションなどに脆弱性がないか調査する 「セキュリティ診断」 においても、セキュアコーディング学習プラットフォーム 「KENRO」 においても、いかに開発者フレンドリーなサービスを提供できるかという点を大事にしています。 そんな弊社はお客様からさまざまな開発におけるセキュリティのアドバイスを求められることも多いのですが、その中で「開発に役に立つセキュリティ」という切り口では、なかなかまとまっているリファレンス集がないという課題に気付かされました。 そこで、社内でアンケートを実施して「開発者にオススメのセ
OAuth 2.0 を参加者全員がある程度のレベルで理解するための勉強会を開催しました | DevelopersIO
現在私は barista という OpenID Connect と OAuth2.0 に準拠したID製品の実装を行っています。 また、私の所属する事業開発部では prismatix というEC、CRM の API 製品の開発を行っていますが、この prismatix の認可サーバーとして barista を利用しています。 barista チームの増員や、prismatix の認可についての理解を促進するため OAuth 2.0 をある程度しっかりと理解しているメンバーを増やしたかったので、勉強会を開催しました。 勉強会の内容 概要 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本を全員で輪読 OIDC 編はこのあとやる予定 攻撃編もやりたい RFC 読んだりもしたい 参加者全員が以下を満たすことが目標 OAuth 2.0 の意図を理解
以下のツイートのブックマークコメントの多くに困惑している。少なくともネット署名、広ければ署名という仕組みに否をつきつけている人がこんなに多いとは。ネット署名や署名の仕組みや目的からして本人確認は無理でしょ。 本オープンレターへの賛同において他人の氏名を勝手に使用する悪戯があったと判断したため、該当の氏名を削除しました。このような悪戯に対して強く抗議します。賛同した覚えがないのにお名前が掲載されている方はレターに追記したメールアドレスまでご連絡ください。https://t.co/waQ53XObZK— KOMIYA Tomone (@frroots) 2022年1月19日 b.hatena.ne.jp 批判が多い「女性差別的な文化を脱するために」の賛同者に賛同した覚えがないのに名前が載っているので困っている人や不快感がある人がいるのはわかる。そして、その人は賛同者から名前を削除してほしいと希
社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意ください。 Twitter: @DddEndow
はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで - エンジニアHub｜Webエンジニアのキャリアを考える！
GitHub Actions入門 ── ワークフローの基本的な構造からOIDCによる外部サービス認証まで GitHubが公式に提供するGitHub Actionsは、後発ながらよく使われるワークフローエンジンとなっています。本記事では、藤吾郎（gfx）さんが、典型的なCI/CDのユースケースに即したワークフローの設定と管理について解説するとともに、注目されているGitHub OIDC（OpenID Connect）の利用についても紹介します。 GitHub Actionsは、GitHubが提供するCI/CDのためのワークフローエンジンです。ワークフローエンジンは、ビルド、テスト、デプロイといったCI/CD関連のワークフローを実行し、定期実行するワークフローを管理するなど、開発におけるソフトウェア実行の自動化を担います。 ▶ GitHub Actions - アイデアからリリースまでのワーク
アプリケーションをユーザに公開する場合, それがGUIであってもCUIであってもインタフェースが必要になります. Webアプリケーションを公開する場合にはWeb APIを利用するのが一般的であり, AWSもAPIをフルマネージドで活用するためのAPI Gatewayを提供しています. 非常に簡単に活用できるのですが細かい機能などを今一度洗い直す機会があればと思っており, 社内勉強会の機会があったのでAPI Gatewayについて話しました. 今回の記事では社内向け勉強会で登壇した内容をブログ向けに再編しています. 資料はSpeakerDeckで公開していますが, 内容についてより細かくこのブログで説明しますので, 是非ご閲覧ください. What is API まず最初にAPIが何かを確認します. 大雑把に伝えるとアプリケーションが呼び出せば予期した結果を返されるような仕組みです. 名前にあ
このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 本プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上（2023年1月末時点）のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS（Identity as a Service）のOkta Customer Identity Cloud（Powered by Auth0）（以下Auth0という）の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
全員がOAuth 2.0を理解しているチームの作り方 #devio2021 | DevelopersIO
DevelopersIO 2021 Decade で「全員がOAuth 2.0を理解しているチームの作り方」というテーマで話させていただきました。 スライド 話した内容 なぜ人類は OAuth 2.0 に入門し続けるのか なぜ OAuth 2.0 をチームに根付かせたいのか 開発フローとしてコードレビューがある 仕様がわからないと、レビューができない コードと仕様のすり合わせのために仕様が分かる必要がある OAuth 2.0 はまあまあややこしい OAuth 2.0 では登場人物が4人いて、それぞれがいろんなやりとりをします。 それぞれのやりとりにパラメーターがあるので、誰が誰にどういう値をどうして送る、みたいなところまで考えるとまあまあややこしいのですが、このややこしいシーケンスを完全に頭に入れると学習がスムーズに進むと思います。 勉強会について 以下をゴールに設定しました。 各ロール
マイクロサービスでの認証認可 - Qiita
複数のクラウドサービスを利用している（マルチクラウド）など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca
SAML入門
【累計3500部突破（商業版含む）🎉】 SAMLaiの道は果てしなく険しい。 本書では、SAML2.0で一般的に多く使用されるフローであるWeb Browser SSOのSP-initiatedとIdP-initiatedと呼ばれるものを中心に、SP側の目線でなるべく簡潔に解説します。 SAML認証に対応してほしいと言われても、もう頭を抱える必要はありません。 筆者自身も何もわからない状態からもがき苦しみながらSAML SPを実装し、数年間サービスを運用してきました。 そのつらい経験を踏まえて、SPを実装する上で今まで触れられることのなかった ・どういう設計が必要か？ ・何を気をつけなければならないか？ のエッセンスを詰め込みました。 SAMLはエンタープライズ用途では求められることが非常に多く、歴史もそれなりに長いものですが、実装する上で必要な体系的な情報はなぜかほとんどありません。
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
複数の言語で同じWebサービスを実装して技術特性の違いを見てみた - Hatena Developer Blog
開発合宿運営チームの id:yutailang0119 と id:maku693 です。はてなでは四半期に一度、技術グループ主導で開発合宿を開催しています（過去の合宿の様子は「開発合宿」カテゴリーにまとまっています）。 2023年4月に実施した開発合宿では、参加者が複数のチームに分かれ、それぞれ異なるプログラミング言語で同じお題のWebサービスを開発しました。言語ごとの特性を比較し、今後の技術選定に生かす取り組みです。 この記事ではその開催レポートをお届けします。 開発言語の特性を理解したい さまざまな技術要素を2日で実装できるお題に 参加チームやコミュニケーションでの工夫 順調に開発が進んだ合宿当日 技術勉強会で「成果物を見る会」を実施 開発合宿を終えて プログラミング言語ごとの使用ライブラリ TypeScript Go Ruby Scala 開発言語の特性を理解したい はてなではたくさ
Retty インフラチームの幸田です。 6月に実施したマイクロサービス強化月間で公開した記事では、マイクロサービス環境を Terraform を利用して刷新した話を書きました。 engineer.retty.me この記事では前回と重複する箇所もありますが、Terraform の CI/CD にフォーカスした内容を書こうと思います。 CI を整備するにあたって意識したこと 「誰でも」かつ「安全に」利用できるように CI 上ですべての作業を完結させる Pull Request によるレビュー環境の整備 バージョンアップ作業の完全自動化 Terraform のディレクトリ構成について リポジトリの運用フロー Terraform によるリソースの追加、変更、削除 tfmigrate によるステートファイルの操作 CI で実行される job について Pull Request をオープンした時 P
AWS 認定 ソリューションアーキテクト – プロフェッショナル(AWS Certified Solutions Architect – Professional)の学習方法 - NRIネットコムBlog
小西秀和です。 この記事は「AWS認定全冠を維持し続ける理由と全取得までの学習方法・資格の難易度まとめ」で説明した学習方法を「AWS 認定 ソリューションアーキテクト – プロフェッショナル(AWS Certified Solutions Architect – Professional)」に特化した形で紹介するものです。 重複する内容については省略していますので、併せて元記事も御覧ください。 また、現在投稿済の各AWS認定に特化した記事へのリンクを以下に掲載しましたので興味のあるAWS認定があれば読んでみてください。 ALL Networking Security Database Analytics ML SAP on AWS Alexa DevOps Developer SysOps SA Pro SA Associate Cloud Practitioner 「AWS 認定 ソリュ
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
こんにちは。アドカレ12/24の記事を簡単にではありますが書かせていただきました。(25日のポストで遅刻ですが) Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2023 - Qiita はじめに 本日のテーマ：思わず天を仰いでしまうID関連システムトラブル 本日のテーマは、みんな大好き「トラブル」の話です。CIAM(Consumer Identity and Access Management)領域のさまざまなシステムにさまざまな立場で関わり、さまざまなトラブルに遭遇してきた経験を踏まえて、クリスマスの合間の気楽な読み物として記載しましたので、一息ついていただければ幸いです。 今回はトラブルの中でも思わず「天を仰いでしまう」激ヤバトラブルにフォーカスして、私的ランキング形式でお届けしたいと思います。 天を仰ぐトラブルとは？ 私
エンジニア全員が Terraform を安心・安全に触れるような仕組みを整えています - VisasQ Dev Blog
はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 ちょっと前に iPhone 15 Pro に変えてようやく USB-C ケーブルに統一できる！と思っていたら、手元にある Magic Trackpad が Lightning ケーブルでしょんぼりしました。 さて今回は、ビザスクのインフラ周りで利用している Terraform をエンジニア全員が安心・安全に利用できる仕組みづくりを行なっている話をしていきます！ これまで ビザスクではインフラの構築・運用に Terraform を利用しており、依頼ベースで DPE のメンバーが Terraform の修正を行なってレビュー＆リリースをしていました。 開発メンバーから Terraform の PR をあげてもらうこともありますが、plan / apply の権限を持っていない
サーバサイドでJWTの即時無効化機能を持っていないサービスは脆弱なのか？ - くろの雑記帳
きっかけ 昨年(2021年9月ごろ)に徳丸さんのこのツイートを見て、「2022年にはJWTを用いたセッション管理に代表される、ステートレスなセッション管理は世の中に受け入れられなくなっていくのだろうか？」と思っていました。 OWASP Top 10 2021 A1に「JWT tokens should be invalidated on the server after logout.」（私訳:JWTトークンはログアウト後にサーバー上で無効化すべきです）と書いてあるけど、どうやって無効化するんだ? ブラックリストに入れる?https://t.co/bcdldF82Bw— 徳丸 浩 (@ockeghem) 2021年9月10日 JWT大好きな皆さん、ここはウォッチしないとだめですよ。これがそのまま通ったら、ログアウト機能でJWTの即時無効化をしていないサイトは脆弱性診断で「OWASP Top
If you’re not using SSH certificates you’re doing SSH wrong
If you’re not using SSH certificates you’re doing SSH wrongUpdated on: June 8, 2023 SSH is ubiquitous. It's the de-facto solution for remote administration of *nix systems. But SSH has some pretty gnarly issues when it comes to usability, operability, and security. You're probably familiar with these issues: SSH user experience is terrible. SSH user on-boarding is slow and manual. Connecting to ne
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
Project Googrename: Google Workspace で 14 年運用されたドメインエイリアスをプライマリドメインに変更 & 全ユーザーを安全にリネームする - クックパッド開発者ブログ
コーポレートエンジニアリング部の id:sora_h です *1。今回は 3 ヵ月ほど前に実施した、Google Workspace テナントのプライマリドメイン変更について、記録を兼ねて説明します。 クックパッドは 2009 年頃 *2 より Google Workspace *3 を利用しています。当社の対外的なメールアドレスは cookpad.com ですが、Google ではプライマリドメインとして cookpad.jp が設定されています。各ユーザーには cookpad.com のアドレスを別名 (エイリアス) として登録されていて、メールアドレスとしては cookpad.com を利用、ただ Google へログインする時だけ cookpad.jp を利用する運用になっていました。想像が出来ると思いますが、これが様々な面で不便・混乱を発生させていました。どうしてこうなった… *
GitLabで1クリックアカウント乗っ取りが可能だった脆弱性から学ぶ、OpenID Connect実装の注意点 - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの森(@ei01241)です。 最近は認証や認可に際してOpenID Connectを使うWebサービスが増えていると思います。「Googleアカウント/Twitter/Facebookでログイン」などのUIはあらゆるサービスで見かけると思います。しかし、OpenID Connectの仕様をよく理解せずに不適切な実装を行うと脆弱性を埋め込むことがあります。 そこで、突然ですがクイズです。以下のTweetをご覧ください。 ⚡️突然ですがクイズです！⚡️ 以下の画面はOAuth 2.0 Best Practice上は推奨されないような実装になっており、潜在的リスクがあります。https://t.co/bXGWktj5fx どのようなリスクが潜んでいるか、ぜひ考えてみてください。このリスクを用いた攻撃についての解説記
GitHub のAutomatically generated release notesを使ってリリースノートの内容を PR に基づいて自動生成するフローを作りました。 今までは、コミットメッセージのルールであるConventional Commitsとconventional-github-releaserを使って、コミットからリリースノートを自動生成していました。 他の人の PR でも、squah merge でコミットメッセージを書き換えることで、リリースノートに反映されるようにしていました。 ただ GitHub に仕組みは違うけどほぼ似たことをするAutomatically generated release notesという機能が実装されているので、これをベースに移行しようと思って、そのワークフローを作っていました。 リリースノート自動生成テクニック - mizdra’s bl
Amazon Web Services ブログ ゼロトラストアーキテクチャ: AWS の視点 本投稿は、AWS の CISO オフィスのディレクターを務める Mark Ryland と AWS Identity の専門家である Quit Van Deman による寄稿を翻訳したものです。 アマゾン ウェブ サービス（AWS）の使命は、安全なシステムの構築、デプロイ、迅速な反復処理を行う際に行う作業がより少なくなるようにお客様に代わってイノベーションを行うことです。お客様からはセキュリティの観点について以下のような質問をよくいただきます、 “システムとデータの機密性、完全性、可用性を適切なレベルに確保し、スピードと俊敏性を向上させるのに最適なパターンは何ですか？“。ゼロトラスト・アーキテクチャまたはゼロトラスト・ネットワーキングのカテゴリーに該当するセキュリティアーキテクチャパターンが、これ
GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです | DevelopersIO
GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです アクセスキー、撲滅してますか？ ナカヤマです。 目黒方面より、以下のような福音が聞こえてきました。 何がどのくらい最高かと言いますと！ GitHub Actions に AWS クレデンシャルを直接渡さずに IAM ロールが使えるようになることがまず最高で！ クレデンシャル直渡しを回避するためだけの Self-hosted runner が必要なくなるところも最高です！！✨✨✨ https://t.co/IUQmfzkIB0 — Tori Hara (@toricls) September 15, 2021 元ネタはこちら。 Ok I blogged about it. That's how excited I am. 1. Deploy this CFN templ
Terraform の CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました - スタディサプリ Product Team Blog
こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor
「Tailscale SSH」が正式版に到達。面倒な鍵管理が不要のSSH、VSCode拡張機能でリモートファイルも編集可能
「Tailscale SSH」が正式版に到達。面倒な鍵管理が不要のSSH、VSCode拡張機能でリモートファイルも編集可能 Tailscale社は、統合的なアイデンティティ管理による鍵管理を不要にした便利なSSHを実現する「Tailscale SSH」が正式版になったことを発表しました。 Tailscale SSH is now out of beta and into general availability! Still juggling SSH keys and managing identities across remote machines? There's a better way: https://t.co/sdvnCckSYg — Tailscale (@Tailscale) March 26, 2024 TailscaleはWireGuardをベースにしたVPN Tai
OAuthの言葉周りを整理する
OAuthの仕組みとToken認証周りの言葉はいつまで経ってもはっきり理解できないものの一つでした。 しかし最近ようやく理解できるようになってきたのでとりあえずそれぞれの言葉の指すものや定義をここで整理してみようと思います。 リフレッシュトークン リフレッシュトークンとは アクセストークンの有効期限が切れたときに、認可サーバーにアクセストークンの更新リクエスト認証をするためのトークン。 OAuth自体はリフレッシュトークンがなくとも実装できるが、リフレッシュトークンはOAuthをより便利にするためのもの。 一般的に有効期限は長い。 ないとどうなるのか アクセストークンの期限が切れたらその度にSNS認証のあのログイン画面に飛ばされてメアドとパスワードの入力が必要になる。 セキュリティに関すること 有効期限が長くても安全性に問題がないと考えられる理由としては、アクセストークンの期限切れ時にしか
CircleCI incident report for January 4, 2023 security incident
CircleCI incident report for January 4, 2023 security incident On January 4, 2023, we alerted customers to a security incident. Today, we want to share with you what happened, what we’ve learned, and what our plans are to continuously improve our security posture for the future. We would like to thank our customers for your attention to rotating and revoking secrets, and apologize for any disrupti
Google Cloud の IDaaS「Identity Platform」で作る、さまざまな認証パターン
Identity Platform を使うと、さまざまな認証パターンが構築できる！ この記事は2023年10月6日に行われたナレッジワークさん主催のイベント「Encraft #7 AppDev with Google Cloud」で発表したセッションの解説記事です。現地でご参加いただいた皆さん、オンラインでご視聴いただいた皆さん、ありがとうございました！ 私のセッションでは Identity Platform を使ったさまざまな認証パターンについてご紹介しました。セッション後、いくつかのご質問や「こんなパターンもあるよ！」というコメントもいただきました(ありがとうございます！)。この記事では、セッション内でご紹介した内容に加え、別解、または発展系とも言えるいくつかのパターンについてもご紹介します。 Identity Platform とは まずはこの記事でメインで扱う Identity P
CircleCI security alert: Rotate any secrets stored in CircleCI (Updated Jan 13)
CircleCI News Last Updated Mar 13, 2023 14 min read Security update 01/12/2023 - 00:30 UTC We have partnered with AWS to help notify all CircleCI customers whose AWS tokens may have been impacted as part of this security incident. Today, AWS began alerting customers via email with lists of potentially impacted tokens. The subject line for this email is [Action Required] CircleCI Security Alert to
フルスクラッチして理解する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 用語の
ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基本の流れであると意識しておきましょう。 パスキーやID連携の
At the time of writing, this functionality exists but has yet to be announced or documented. It works, though! EDIT: Here is the functionality on the GitHub roadmap. GitHub Actions has new functionality that can vend OpenID Connect credentials to jobs running on the platform. This is very exciting for AWS account administrators as it means that CI/CD jobs no longer need any long-term secrets to be
『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』の予習・復習用情報 - Qiita
はじめに Authlete（オースリート）社主催の勉強会『いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい』（2020 年 1 月 31 日（済）, 2020 年 2 月 21 日（中止））の内容がてんこ盛り過ぎるため、予習・復習用の情報を書き出そうと思います。 追記 2020 年 1 月 31 日の勉強会の資料と動画（字幕付き）を公開しました！ OAuth / OIDC 勉強会参加者は、OAuth 2.0（オーオース）と OpenID Connect（オープンアイディー・コネクト）の基本を知っていることが前提となります。 OAuth 2.0 は「アクセストークンを発行する仕組み」です。その中心となる仕様は RFC 6749 です。詳細については『一番分かりやすい OAuth の説明』と『OAuth 2.0 全フローの図解と動画』をご参照ください。 Op
いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。 こんにちは、富士榮です。 なんだかんだでuPortを触ったり現Azure Active Directory Verifiable Credentialsの前身を触ったり、最近だと数カ所で実証実験プロジェクトを立ち上げたり、MS主催のDecentralized Identity Hackathonで入賞してみたり、と分散型IDに関わり始めて5年くらい経っていたりしますので、現時点で分かったことをメモしておこうかと思います。（往々にして数年後に見返すとう〜ん、となるやつだけど気にしないことにする） ※そういう意味では2019年の#didconでその時点でわかっていることをある程度まとめて発表してからおよそ3年も経つんですね・・・ また機会があればdidconでも開催してじっくりお話さ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OAuth認証とは何か?なぜダメなのか - 2020冬 - r-weblife
図解 X.509 証明書 - Qiita
（ネット）署名という仕組みに否を突き付けている人が多くて困惑している - 発声練習
30分でOpenID Connect完全に理解したと言えるようになる勉強会
OAuth 2.0 クライアント認証 - Qiita
Amazon API Gateway は何をしてるのか | DevelopersIO
「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
100万ユーザーをログアウトさせずに新認証基盤に移行した話
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
Retty の Terraform CI/CD 解体新書 - Retty Tech Blog
毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
思わず天を仰いでしまうID関連システムトラブル - =kthrtty/(+blog)
Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
GitHubのリリースノートを自動化する仕組み
ゼロトラストアーキテクチャ: AWS の視点 | Amazon Web Services
パスキーとID連携の認証フローの共通点から見る認証技術の基本
AWS federation comes to GitHub Actions
分散型IDに関する10の所感（2022年2月版）