タグ

認証・認可に関するimaizmのブックマーク (25)

  • OAuthの仕組みを説明してHonoで実装してみる

    はじめに はじめまして!レバテック開発部でレバテックプラットフォーム開発チームに所属している塚原です。 直近に認証・認可周りの改修を予定しているため、チーム内で認証・認可の基礎からOAuth・OpenID Connectの仕組みを学ぶ勉強会を実施しました。今回はそこで学んだことのうち、認証・認可の基礎とOAuthの仕組みをまとめます。また、WebフレームワークとしてHono、JavaScriptランタイムとしてBunを使って、OAuthクライアントを実装してみます。 対象読者 認証と認可の違いってなんだっけ...?という人 Basic認証やDigest認証てなんだっけ...?という人 OAuthはライブラリ使って実装してるから仕組みよくわかっていない...という人 OAuthのクライアントの実装って何をすればいいんだっけ...?という人 認証・認可の基礎 2024/7/18 追記 こちらで

    OAuthの仕組みを説明してHonoで実装してみる
  • 「認証」を整理する | IIJ Engineers Blog

    英語の「Authentication」を整理する ここからは先ほどの分類で言うところの「ユーザ認証」としての「認証」、つまり英語の「Authentication」に該当する「認証」について、さらに整理を進めていきます。 先ほど、「ユーザ認証」を「システムを利用しようとしているユーザを、システムに登録済みのユーザかどうか識別し、ユーザが主張する身元を検証するプロセス」と説明しました。「ユーザの識別」と「身元の検証」はユーザ認証に欠かせませんが、実際は他にも「ユーザの有効/無効状態の確認」や「検証に成功した場合の身元の保証(アクセストークンの発行等)」などの処理も一般的にユーザ認証のプロセスには含まれます。 ここで冒頭の「○○認証」を振り返りましょう。パスワード認証、SMS認証、指紋認証、顔認証は実はここで言うユーザ認証には該当せず、ユーザ認証中の一処理である「身元の検証」を担っていることがお

    「認証」を整理する | IIJ Engineers Blog
  • 滅びてほしい認証系の実装の話

    こんにちは、富士榮です。 ちょっと前に某所でダメダメな認証系の技術実装ってなんだろうねぇ、、という話をしていたことをXで呟いたところ、色々とご意見を頂けましたのでまとめて書いておきます。

    滅びてほしい認証系の実装の話
  • パスキーとID連携の認証フローの共通点から見る認証技術の基本

    ritou です。 少し前にパスキーとID連携の関係を考えるときにこういう観点があるよという話をしずかな方に書きました。 今回は、ログインに利用しようとした時のフローの中でここ似ているよね、こんな意図があるんだよっていう部分を取り上げます。 認証フローの似ている点 登場人物をUserAgent、RP、Authenticatorとして、あらゆるところを簡略化したシーケンスを用意しました。 ID連携、いわゆるソーシャルログインでは次のようになります。 登場人物をUserAgent、RP、IdPとするとこんな感じでしょう。 もちろん細かいところは違うわけですが、全体の流れは似ています。 WebAuthnのchallenge, OIDCのnonce, state 先ほどのシーケンス、たまたま似ていると言うよりも、これは認証フローにおける基の流れであると意識しておきましょう。 パスキーやID連携の

    パスキーとID連携の認証フローの共通点から見る認証技術の基本
  • 認可のベストプラクティスとDDDでの実装パターン

    最近、少々複雑な権限機能の開発を担当している中で、対応方針を悩んでいたことがありました。 権限機能というものは取り扱いが難しく、影響範囲が広いにも関わらず、対応漏れや考慮不足があると情報漏洩に繋がってしまいます。 また、機能拡張をしてく中でも対応漏れを起こさないようにする必要があるなど、考えることも多く頭を悩ませておりました。 そこで、認可処理の設計のベストプラクティスやDDDの実装パターンに認可処理を組み込む方法など、色々と調べていたのですが、その中でいくつか知見を得られたのでまとめようと思います! 権限と認可 権限と切っては切れない関係にあるのが認可です。 権限はある操作を実行できる権利を指します。 それに対して、認可は操作を実行する許可を出すため仕組みのことを指します。 例えば、ブログ投稿サービスで考えてみると、以下のような感じです。 権限: 投稿者はポストを編集できる。 認可: ユ

    認可のベストプラクティスとDDDでの実装パターン
  • プログラマのための公開鍵による暗号化と署名の話

    初めに 公開鍵による暗号化と署名をプログラマ向け(?)に書いてみました。ちまたによくある暗号化と署名の話はインタフェースと実装がごちゃまぜになっていることが分かり、暗号化と署名の理解が進めば幸いです(と思って書いたけど、余計分からんといわれたらすんません)。登場する言語は架空ですが、多分容易に理解できると思います。 公開鍵による暗号化PKE 早速、公開鍵による暗号化(PKE : Public Key Encryption)を紹介します。登場するのは暗号化したいデータのクラスPlainText, 暗号文クラスCipherText, 秘密鍵クラスPrivateKeyと公開鍵クラスPublicKeyです。PKEは次の3個のインタフェースを提供しています。 abstract class PKE { abstract keyGenerator(): [PrivateKey, PublicKey];

    プログラマのための公開鍵による暗号化と署名の話
  • APIトークン認証の論理設計

    SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です(しかもデフォルトでは有効期限なし)。 有効かどう

    APIトークン認証の論理設計
  • 【NextAuth.js 入門】認証機能から認証情報によるページの表示制御を学ぶ(Next.js & Typescript)

    NextAuth.js 入門】認証機能から認証情報によるページの表示制御を学ぶ(Next.js & Typescript) アプリケーションを開発するにあたって、避けて通れないのが認証機能の実装です。 書籍では、NextAuth.js を使って Next.js で作成したアプリケーションに認証機能を実装していきます。さらに、認証情報を使って、表示するページの制御も行います。 認証情報によるページの表示制御にはいくつか方法がありますが、書籍では NextPage 型を拡張した CustomNextPage 型を作成することによって、ページの表示制御を実現します。 一緒に NextAuth.js による認証機能を学んでいきましょう。

    【NextAuth.js 入門】認証機能から認証情報によるページの表示制御を学ぶ(Next.js & Typescript)
  • パスワードレス時代のOpenID Connectの活用 / 20230404-OAuth-Numa-Workshop

    OAuth Numa Workshop 2023での講演資料になります。 https://openid.connpass.com/event/275302/ SMS・メールを利用した認証やFIDOによるパスワードレスの認証が普及し始めています。 一方でFIDOなどの手段はまだ対応のハードルが高…

    パスワードレス時代のOpenID Connectの活用 / 20230404-OAuth-Numa-Workshop
  • セッション認証とトークン認証について

    概要 セッション認証とトークン認証について整理する。下記サイトで詳しく解説されていたので、自分はあくまで学びをアウトプットする目的として記事を作成する。詳しく学びたい人は、こちらで確認してほしい。 早速だがセッション認証とトークン認証について、一言で言うと、セッション認証はサーバー側主体の認証方法であり、トークン認証はブラウザ側主体の認証方法である。 セッション認証 セッション認証は、ユーザがログイン成功した際に、ユーザ情報と紐付けたセッションIDを返す。ユーザはこのセッションIDをブラウザ上でクッキーとして保存して、サーバー側へリクエストを送る。具体的な流れを下記に示す。 ユーザがログイン認証を経て、サーバがユーザ情報と紐づけたセッションIDを発行する。 発行されたセッションIDをユーザのブラウザが受け取り、クッキーとして保存する。 クッキーとして保存されたセッションIDを用いて、ユー

    セッション認証とトークン認証について
  • IdPとしてSAML認証機能を自前実装した - BASEプロダクトチームブログ

    はじめに みなさんはじめまして。BASEでエンジニアをしております田村 ( taiyou )です。 先日、BASEではショップオーナー向けのコミュニティサイト「BASE Street」にログインするための機能としてSSOログイン機能をリリースしました。 SSOログインを実現するための認証方式はいくつかあるのですが、弊社ではSAML認証方式を用いて実現しました。 そのため、この記事ではSAML認証機構のIdPとしてOSSを使わずにSAML認証機能を実装する方法を紹介します。 前回のテックブログで、このSSOログイン機能のフロント側を開発したPJメンバーの若菜が「サーバーサイドエンジニアフロントエンドに挑戦して最高の経験になった話」を執筆したのでこちらも見てみてください! SAML認証機能を提供しているOSSには、Keycloakなどがありますが、BASEでは以下の理由により自前実装すること

    IdPとしてSAML認証機能を自前実装した - BASEプロダクトチームブログ
  • SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ

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

    SPA認証トークンはlocalStorageでもCookieでもない、Auth0方式はいいねというお話 - @mizumotokのブログ
  • 「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete

    このビデオについて このビデオは、2021 年 10 月 6 日に開催された 「挫折しない OAuth / OpenID Connect 入門」の理解を深める会 のプレゼンテーション録画です。 2021 年 9 月 18 日発売の「Software Design 2021 年 10 月号」では、OAuth/OIDC が特集され、「挫折しない OAuth/OpenID Connect 入門・API を守る認証・認可フローのしくみ」と題し、Authlete 代表の川崎貴彦が寄稿しました。 プレゼンテーションでは記事のポイントや、理解を深めるために重要なポイントについて、著者の川崎がお話しします。 文字起こし はじめに 目次 記事の第1章、第2章、第3章は、こういう目次になっています。 ここからピックアップして、 こんなことを話してます、というところを、 紹介したいと思います。 自己紹介 Au

    「挫折しない OAuth / OpenID Connect 入門」のポイント - Authlete
  • OAuthにおける認可コード横取り攻撃とその対策

    OAuthにおける認可コード横取り攻撃とその対策 Jul 5, 2021 前回の記事で示したように、カスタムURLスキームを偽装した不正アプリは正規アプリへのディープリンクを乗っ取れる。この挙動の悪用シナリオとして、正規アプリと認可サーバー間のOAuthフローにおける認可コード横取り攻撃が知られている。この攻撃への対策を把握するためにiOS環境でシナリオを再現し、PKCEの有効性を確認した。 要約 OAuth 2.0の拡張機能であるPKCEを導入することで認可コード横取り攻撃を無効化できる。OAuth 2.0の仕様では、認可サーバーはネイティブアプリをクライアント認証できない。そのため、認可サーバーは認可コードを横取りした不正アプリと正規アプリを識別できない。しかし、PKCEの仕組みにより認可サーバーは正規アプリを識別できるようになり、認可コード横取り攻撃の検知が可能となる。 ネイティブア

    OAuthにおける認可コード横取り攻撃とその対策
  • 認証用トークン保存先の第4選択肢としての「Auth0」

    iCARE Developer Meetupは、月次で開催している株式会社iCAREが主催するエンジニア向けのLT勉強会です。18回目の今回は、Ruby on Railsをテーマに行いました。サーバーサイドエンジニアの越川氏からはToken認証機能について。 Rails APIモードで開発するときの認証用のトークンはどこに保存すればいいの問題 越川佳祐氏:私からは、「Rails APIモードにおけるToken認証機能について」というテーマでLT(ライトニングトーク)をしようと思っていたんですが、スライドを作っていて「あれ、これ別にRailsだけの話じゃなくない?」と思ってしまいました。みなさんの中にも、そう思う方がいるかもしれないんですが、もうこれで作っちゃったのでご了承ください。 私は株式会社iCAREで、サーバーサイドエンジニアをしている、越川と申します。Twitterは@kossy0

    認証用トークン保存先の第4選択肢としての「Auth0」
  • 世界一わかりみの深いOAuth入門

    世界一わかりみの深いOAuth入門

    世界一わかりみの深いOAuth入門
  • CloudfrontとS3でBasic認証をかける - Qiita

    S3 bucketの作成 まずはhtmlファイル等を格納するS3のbucketを作成します。 Cloudfrontから配信するのでパブリックアクセス許可やStatic website hostingの設定は不要です。 lambda関数の作成 次にBasic認証を処理するlambda関数を作成します。 この時、右上のリージョン設定で「バージニア北部」を選択してから「関数の作成」をしてください。 名前に"BasicAuthentication"(任意の名前) ランタイムはNode.js 6.10を選択 ロールは"テンプレートから新しいロールを作成"を選択 ロール名には"lambda_edge_exection"(任意の名前) ポリシーテンプレートは"Basic Edge Lambdaアクセス権限"を選択 関数の作成をクリックしてしばらくすると次の画面に切り替わります。 少しスクロールしたところ

    CloudfrontとS3でBasic認証をかける - Qiita
  • 認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本

    認証と認可についての知識が必要になったので、基礎的なことを学んでいます。 一切何も知らない状態から手当たり次第に細かく調べるのは大変だったので、超サマリを整理してみようと思います。 このは「個々の要素に詳しくなる必要はないんだけど、概要くらいはさっと把握しておきたい」とか「手当たり次第に詳細調査をする前に、一瞥してこれから踏み込もうとしている領域の超俯瞰マップを作る」という感じで使うことを想定しています。 同じ様な方の役に立ったら、とても嬉しいです。 このは筆者の理解に連動して追記修正される可能性があります。

    認証と認可の超サマリ OAuth とか OpenID Connect とか SAML とかをまとめてざっと把握する本
  • マイクロサービス時代のセッション管理 - Retty Tech Blog

    この記事はRetty Advent Calendar 2019 21日目の記事です。エンジニアの 神@pikatenor がお送りします。11日目の記事に書かれた「弊社エンジニアの神(注・人名であり実名です)」とは私のことです。 qiita.com さて世はまさにマイクロサービス大航海時代、大規模化した組織・肥大化したコードベースのメンテナンスを継続的に行っていくべく、アプリケーションを機能別に分割する同手法が注目を集めていることは皆さんもご存知でしょう。 マイクロサービスアーキテクチャ特有の設計課題はいくつかありますが、今回は認証情報のような、サービス間でグローバルに共有されるセッション情報の管理のパターンについて調べたことをまとめてみたいと思います。 背景 HTTP は質的にステートレスなプロトコルですが、実際の Web サービス上では複数リクエストをまたがって状態を保持するために、

    マイクロサービス時代のセッション管理 - Retty Tech Blog
  • なぜWebサービスの選定においてSAML/SSOが重要なのか

    TL;DRクラウドネイティブな時代のビジネスではWebサービス活用は必須Webサービスをセキュアに利用していくには管理やセキュリティ面での工数・コストが増えるこの工数・コストを下げることこそがWebサービス活用推進ひいてはビジネスの加速に繋がる工数・コストを下げる為に導入するWebサービスにSAML/SSOは必須ログインをSAML/SSOに限定出来ることまでがマストWebサービス利用におけるセキュリティ面で一番重要なのがID周り個々のWebサービスセキュリティ対策よりもID管理に特化したシステムに任せた方がよっぽどセキュア(屋)Webサービス導入時には値が張ってもSAML/SSO出来るプランで契約するSAML/SSOが出来ないことによるデメリット(工数・コスト)の方が、SAML/SSOを有効にできるプランにアップグレードする費用に勝るB2BのWebサービスを提供する企業は全プランに

    なぜWebサービスの選定においてSAML/SSOが重要なのか