はじめに React/Next.js で、認証・認可を実装するには、さまざまなソリューションが存在します 🫐 自前で実装するというのも１つの選択肢ですが、 セキュアな認証システムを一から構築するには、多くの時間と労力、そして継続的なメンテナンスが必要になります。 なので、認証周りは、外部のサービス・ライブラリを導入するケースが多いですよね。 Firebase auth supabase auth Lucia Auth.js Auth0 Clerk など、が有名どころでしょうか。 その中でも、今回は認証サービス Clerk について調査したので、基礎的な内容をまとめました！ 時間の節約になれば、嬉しいです 🙌 Clerk とは？ 最も包括的なユーザー管理プラットフォーム Clerk は、モダンな Web アプリケーション向けに、認証から、ユーザー管理機能まで、包括的なサービスを提供してい
この記事は、Techouse Advent Calendar 2024 6日目です。 昨日は nozomemein さんによる Active Storageを使った画像のCORS対応で沼った話 でした。 はじめに こんにちは、2024年に新卒で入社し、クラウドハウス労務でバックエンドエンジニアをしているdaiki_fujiokaです。 本記事では、私が設計・実装を担当した2FA機能について、開発中に得られた知見や学んだことについて紹介します。 現状と課題 クラウドハウス労務では企業向けの人事労務管理サービスを提供しています。利用企業は従業員に対してアカウントを払い出し、従業員は自身のアカウントにログインして各種労務手続きを行います。 クラウドハウス労務のログイン方式には外部サービスであるAuth0を利用したOpenID Connect(以下OIDC)を利用しています。 OIDCには認証機能
パスキーのクレデンシャルがベンダ間で交換可能に、業界標準「Credential Exchange Specifications」ワーキングドラフトをFIDOアライアンスが公開 パスワードレスを実現する業界標準「パスキー」（Passkey）の仕様策定や推進を行っているFIDOアライアンス（ファイドアライアンス）は、クレデンシャルを安全に交換するための新仕様「Credential Exchange Specifications」のワーキングドラフトを発表しました。 これによりユーザーはパスキーやその他すべてのクレデンシャルを、異なるベンダ間であっても安全に移動や交換できるようになります。 例えば、Googleパスワードマネージャに保存されたパスキーのクレデンシャルをAppleアカウントのiCloudキーチェーンへ移動してiPhoneでパスキーを使う、あるいは1Passwordなど他のパスワード
こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。
なお、上記は2023年12月時点でのFIDOアラインスの定義に基づきます。これらの用語はこれまで定義が変化してきたり、FIDOアライアンスの定義が業界のコンセンサスを得ていないケースで意味の揺れがあったりすることもありました。 同期するもののみを指すケース パスキーはFIDOアライアンスの発表では、「マルチデバイスFIDOクレデンシャル」の通称という扱いでした34。つまり、当初はクラウド同期して複数デバイスで使えるもののみがパスキーでした。しかし、パスキーの勢いを見てか分かりませんが、セキュリティキーベンダーが自分たちもパスキーだと主張し始めました5。その後FIDOアライアンスもSingle-device passkey(現: デバイスバウンドパスキー)を定義し、同期しない従来のFIDOクレデンシャルもパスキーとなりました6。 認証方式を指すケース パスキーは「FIDOクレデンシャル」です
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2023 の11日目の記事です。 最近、パスキーのことばかり考えていましたが、その中だったり、別の文脈だったりで、「認証の強度や身元確認レベルと利用可能な機能の関係」を考える機会が、ちょいちょいありました。 例えば『パスキーでアカウント登録するを実施するのが理想的だよね』という意見を聞きます。その一方で、『パスキーでphishingの対策はできるかもしれないけど、誰でも簡単にアカウント作れたらだめだから、電話番号の登録はどのみち必要。
パスキーの登場以来、ID連携、特にソーシャルログインは認証方法として比べられることが多くなりました。この記事では、この2つを比較したりその関係を考察する際に意識しておくべき観点を整理しておきます。 それぞれの特徴両者は異なる特徴を持っています。 パスキー 用途: 認証 パスキーの管理: プラットフォームが提供するパスワードマネージャー、サードパーティーのパスワードマネージャー、セキュリティキー、ブラウザ 属性情報: 一緒に保持できて引き回せるデータは User Handle ぐらい ID連携 用途: 新規登録、認証、属性情報の取得/同期 アカウント情報の管理: Identity Provider 属性情報: プロフィール情報、確認済みメールアドレスなどを取得可能なのが一般的 特徴が異なるために、導入箇所や意味合いも異なります。 ざっと思いつくのが 新規登録 ログイン 再認証 ぐらいでしょう
はじめに Auth屋さんの本やその他有識者のBlogなどを読むことで少しながらOAuthやOIDCの仕組みが理解できてきました。 そんななかで以下の記事が大変勉強になりました。 ↑の記事ではRubyで実装されているのですが、これを参考というかほぼ丸コピですがgolangで実装してみたいと思います。 コードは以下にあります。 仕様 OAuthサーバでは認可エンドポイントとトークンエンドポイントを実装する必要があります。 認可とトークンエンドポイントの2つに加えてユーザ認証を行うエンドポイントを作ります。 今回は元記事と同じようにFormに入力したユーザ&パスワードを受け取り確認します。 RFC6749に関する仕様は元記事の2.注意点と同じになるはずです。 「はずです」というのは恥ずかしながらまだ完全な理解に至っておらず今もRFCを読みながら答え合わせ中です。 ぜひ認識違いがあればご指摘くださ
※この投稿は米国時間 2021 年 5 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。 2021 年用に更新: この投稿には、Google のホワイトペーパー「パスワード管理のベスト プラクティス」のユーザー向けとシステム設計者向けの両方の最新情報を含む、更新されたベスト プラクティスが含まれています。 アカウント管理、認証、パスワード管理には十分な注意を払う必要があります。多くの場合、アカウント管理は開発者や製品マネージャーにとって最優先事項ではなく、盲点になりがちです。そのため、ユーザーが期待するデータ セキュリティやユーザー エクスペリエンスを提供できていないケースがよくあります。 幸い、Google Cloud には、ユーザー アカウント（ここでは、システムに対して認証を受けるすべてのユーザー、つまりお客様または内部ユーザー）の作成、安全な取り扱い、
OpenID Connect 1.0は、OAuth 2.0をベースとした認証プロトコルです。このセッションでは次の内容をわかりやすく解説します。 - OpenID Connect 1.0の概要とフロー - なぜOAuthは「認可」でOpenID Connectは「認証」なのか - Spring Securityの利用方法 このセッションは中級者向けです。次の知識を前提として解説します。 - OAuth 2.0の認可コードグラントのフローを説明できる - Spring Security 5.xのOAuth 2.0機能を使ったことがある（既に非推奨となっている「Spring Security OAuth2」ではありません）
Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim. Digital Identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in t
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは!! Yahoo! JAPAN研究所の山口修司です。 突然ですが、生体認証は好きですか？ 最近はスマホで生体認証が利用できるようになったので生体認証を使うシーンが増えていると思います。私は、使い勝手的に（以後ユーザビリティと書きます）、パスワードを覚えたり入力したりしたくないので、生体認証が選べるなら積極的に使っています。 Yahoo! JAPANでは、2018年にセキュリティとユーザビリティの両立を目指して、Yahoo! JAPAN IDに生体認証を導入しました。 ヤフー、Androidスマートフォンのウェブブラウザー上でのログインが指紋認証などの生体認証に対応 Webサイトの生体認証の仕組みには、認証に関するグローバ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 世の中の OAuth & OpenID Connect の不適切実装の事例をリストしています。公式ドキュメントに「ドラフト段階の仕様をサポート」と断り書きが書いてあっても、最終仕様に違反している場合はリストしています。内容は適宜更新していきます。OAuth & OpenID Connect を実装する際の注意事項として参照していただければと思います。 仕様書を読むのは面倒だけど、OAuth & OpenID Connect をちゃんと実装しないといけない立場にある方は、是非 Authlete の使用を検討してください。(by
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く