デジタル認証アプリとのID連携で使われている標準化仕様と勘所
ritou です。 みんなが待っていたデジタル認証アプリの情報が公開されました。 開発者向けのガイドライン、APIリファレンスなどのドキュメントも公開されています。 今回は開発者視点でどんな作りになっていて、利用するために理解が必要となる標準化仕様はどのあたりなのかを取り上げます。ちょっとOIDCのRPやOAuthのClient実装経験のある開発者向け、ぐらいの内容です。 概要 公開された情報からすると デジタル認証アプリサービス(アプリ+バックエンド)はマイナンバーカードを用いた当人認証を実施 現在は都度マイナンバーカードを利用する必要がありますが、いずれはスマホに保存されたカード情報を使ってもっと楽になりそう ID連携のIdentityプロバイダとして認証イベント情報、基本4情報といった属性情報を民間/行政サービスに提供 民間/行政サービスは認証イベント情報に含まれるユーザー識別子を利
行政機関等・民間事業者向け実装ガイドライン | デジタル認証アプリ | ドキュメント | デジタル庁 開発者サイト
概要「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。行政機関や民間事業者は、デジタル認証アプリと連携するAPIを活用することで、マイナンバーカードを使った本人確認・認証や電子申請書類への署名機能を簡単に組み込むことができます。 サービスの概要については、以下の情報をご確認ください。 行政機関向け情報民間事業者向け情報認証・署名のプロセスはOAuth 2.0 認可コードフロー、およびOpenID Connect 認可コードフローに基づきます。 署名プロセスのみ、認可コードフローにて署名処理を実施するためにクライアントクレデンシャルズフローが扱われます。 必要に応じて、トークンリフレッシュフローにてトークンのリフレッシュを行うことが可能です。 ※「リソースオーナーパスワードクレデンシャルズフロー」ならびに「インプリシッ
滅びてほしい認証系の実装の話
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
Firebase Authから内製認証基盤に無停止移行して年間1000万円以上削減した
症状検索エンジン「ユビー」 では、ローンチ当初から Firebase Auth (GCP Identity Platform) を使っていましたが、OIDCに準拠した内製の認証認可基盤に移行しました。 認証認可基盤そのものは m_mizutani と nerocrux と toshi0607(退職済) が作ってくれたため、僕は移行のみを担当しました。 結果として、強制ログアウトなし・無停止でビジネス影響を出さずに、年間1000万円以上のコスト削減に成功しました[1]。その移行プロセスについて紹介します。認証認可基盤そのものの紹介はあまりしません。 移行した理由 大量の匿名アカウント ユビーでは、アクセスした全ユーザーに対して自動的に匿名アカウントを発行しています。これにより、ユーザーがアカウント登録しているかどうかに関わらず、同じID体系で透過的に履歴情報等を扱うことができます。アカウント
OIDCを利用した個人的なWEBシステムで認証情報を何をもって維持するのか考えてみた
個人開発を何度もしてきて、何一つとしてリリースしてない私が考えてみました。 リリースしないというセキュリティ担保では、やはり駄目だろう、と。 駄目なんだろうな、と思い、自分なりに整理してみました。 個人的な結論 結論から話せ、と世の中がいうので結論から言います。 OIDCの処理はバックエンドで行えるならバックエンドで行う ブラウザから利用するWebシステムならCookieを使えば良い せっかくだしcookieにはJWTを入れておけばいい 個人的にはこんな感じでいいんじゃないかと思いました。 理由はここから先に記載します。興味があったら見てください。 セキュリティは難しいし、得意じゃないのでご指導ご鞭撻は優しくしてください。(祈り) OIDCの処理はどこに置くのがいいのか OIDC自体はブラウザで結果を受け取ることも、サーバで受け取ることも可能です。 ということは、まずそもそもどこで完結させ
週刊Railsウォッチ: Rails 7.1で「Apple でサインイン」を実装、JetBrains AIほか（20231215後編）｜TechRacho by BPS株式会社
週刊Railsウォッチについて 各記事冒頭には🔗でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄 お気づきの点がありましたら@hachi8833までメンションをいただければ確認・対応いたします🙏 TechRachoではRubyやRailsなどの最新情報記事を平日に公開しています。TechRacho記事をいち早くお読みになりたい方はTwitterにて@techrachoのフォローをお願いします。また、タグやカテゴリごとにRSSフィードを購読することもできます（例:週刊Railsウォッチタグ） 🔗Rails 🔗 rage: Rails互換の高速APIフレームワーク（Ruby Weeklyより） つっつきボイス:「Railsっぽく書ける軽量かつ高速
認証と署名の整理をしましょう（またかよ） - Qiita
はじめに 去年の「Digital Identity技術勉強会 #iddanceAdvent Calendar 2022」でも「認証と署名は何が違う？ ～マイナンバーカードを例に～」として認証と署名の話をしました。実は今年も必要に迫られて認証と署名の整理をしてきてある程度まとまったかな…と言うことで今年も再び書かせてください！また署名業界では新たに電子シール（eシールとも呼ばれる非自然人/組織の電子証明書によるデジタル署名）の検討が進んでいます。なので署名も電子署名と電子シールに分けて整理をしてみます。年末の忙しい時期ですが楽しんでご笑読ください。認証と署名の整理についてはこれで最後にしたい…なぁw デジタルアイデンティティ さてまず認証と署名を比較するとはどういうことかを整理しましょう。認証…と言うよりも技術全体を示すのであれば最近はデジタルアイデンティティ（Digital Identit
パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~
ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単！けどこれ指紋認証だけ？弱くなってない？ SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった？ この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする
100万ユーザーをログアウトさせずに新認証基盤に移行した話
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上（2023年1月末時点）のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS（Identity as a Service）のOkta Customer Identity Cloud（Powered by Auth0）（以下Auth0という）の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
Auth.js | Authentication for the Web
// auth.ts import NextAuth from "next-auth" import GitHub from "next-auth/providers/github" export const { auth, handlers } = NextAuth({ providers: [GitHub] }) // middleware.ts export { auth as middleware } from "@/auth" // app/api/auth/[...nextauth]/route.ts import { handlers } from "@/auth" export const { GET, POST } = handlers // src/auth.ts import { SvelteKitAuth } from "@auth/sveltekit" impor
ウェブ認証 API - Web API | MDN
This feature is well established and works across many devices and browser versions. It’s been available across browsers since September 2021. Learn moreSee full compatibilityReport feedback ウェブ認証 API (別名 WebAuthn) は、ウェブサイトで登録、認証、二要素認証を行うためにパスワードや SMS のテキストを使用するのではなく、公開鍵暗号を使用します。これにはいくつかの利点があります。 フィッシングからの保護: 偽のログインサイトを作成した攻撃者は、サイトのオリジンで署名が変わるため、ユーザーとしてログインすることができません。 情報漏洩の影響を軽減: 開発者は公開鍵をハッシュ化する必要
WebAuthnとは？ - Qiita
一週間も間をおかずアドベントカレンダーの記事を書くのはしんどいですね笑 本当は認証サーバーの実装とかもやりたかったんですが、時間がなくてだいぶざっくりした内容になっちゃってます。概要を掴むのに使っていただければ幸いです。 Q. WebAuthnとは？ A. ざっくり言うとパスワードレス認証をwebで行えるようにしたJavascriptAPIです。 各種ブラウザで実装されています。 経緯などは特に役立つものではないので省きます。 知りたい方はこちらが詳しいです。 何ができるの？ A. 認証器と言われるデバイスを通して、パスワードなしで認証が行えます。 具体的には、webサイトのログイン画面で指紋認証やセキュリティーキーでの認証を使ってログインが出来ます。 ↓指紋認証の認証器として使えるMacBook ProのTouch ID ↓セキュリティーキーの一例 何がいいの？ A. 楽で安全です。 な
Linuxの各アプリケーションが共通して利用する「PAM認証」について
Linuxのユーザ認証に関することならPAM認証におまかせ！ 前回はスパムメール対策にユーザー認証を利用することを解説しました。 Linuxではメールサーバだけでなく、多くのアプリケーションでユーザー認証を行います。ユーザー認証が必要なソフト全てに、別々の認証機構やデータベースを追加するというのは無駄が多くなります。 そのため「PAM（パム：Pluggable Authentication Modules）」という「各ソフト共通で利用できる認証システム」が用意されています。これからメールサーバにSMTP認証を導入するにあたって「PAM認証」を利用するので、仕組みを理解しておきましょう。 PAM認証について 「PAM認証」を簡単に解説すると下の図のようになります。 このイラストの例で言えば、「DNSサーバ」と「SMTPサーバ」が共にPAM認証を利用。「PAM認証」に利用されている認証機構はシ
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
アプリで「ログインしっぱなし」はどのように実現されているか？ - Qiita
このツイートを見て、「アプリで再ログインを頻繁要求されるってユーザビリティ良くないな。」と思ったのですが、普段裏側の仕組みは意識していなかったりテックリードの方に任せきりだったりしていたので、これを機に調べてみました。 そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。（何を言ってるかわからねえだろうと思うが。） — Hiromitsu Takagi (@HiromitsuTakagi) 2019年7月8日 この記事は「アプリでログインしっぱなしは、どのように実現されるの？」という疑問と調べた結果を共有するために書いていきます。 間違いや「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！ 疑問1. アクセストークンという仕組みとは？ 「なぜアクセストークンという概念が必要なのか？」 モバイルアプリでユーザー認証をし
Set up your own custom SAML app - Google Workspace Admin Help
Single sign-on (SSO) lets users sign in to all their enterprise cloud apps using their managed Google Account credentials. Google offers preintegrated SSO with over 200 popular cloud apps. Perform these steps to set up SAML-based SSO with a custom app that is not in the preintegrated catalog. Click Add AppAdd custom SAML app. Enter the app name and, optionally, upload an icon for your app. The app
WebAuthnでパスワードレスなサイトを作る。安全なオンライン認証を導入するFIDOの基本 - エンジニアHub｜Webエンジニアのキャリアを考える！
WebAuthnでパスワードレスなサイトを作る。安全なオンライン認証を導入するFIDOの基本 FIDO（Fast IDentity Online）とは、公開鍵認証方式を応用し、オンライン経由で認証を行う仕組みです。パスワード認証の安全性は限界が指摘されるなか、Webサイトにおいても生体認証などパスワードレスな仕組みを導入する企業が増えており、このFIDOやWebAuthnに注目が集まっています。Capy株式会社で情報セキュリティに関する研究開発や分析などに携わる、松本悦宜さんの解説です。 こんにちは、松本悦宜（@ym405nm）です。 FIDO（ふぁいど）に関しては、昨年（2018年）から多くのメディアや技術ブログで取り上げられ、導入するWebサイトも増えています。 FIDO2プロジェクトにおいて話題になったWebAuthn（Web Authentication API）についても、主なW
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヤフー、パスワードなし認証への移行推奨。フィッシング報告増加を受け 4月の報告件数は「過去最高レベル」
認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本
Auth0：誰もが安全にアクセスするために。でも、誰でもというわけではありません。
